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Abstract 



Java is typically compiled into an intermediate language, JVML, that is interpreted 
by the Java Virtual Machine. Because mobile JVML code is not always trusted, 
a bytecode verifier enforces static constraints that prevent various dynamic errors. 
Given the importance of the bytecode verifier for security, its current descriptions 
are inadequate. This paper proposes using typing rules to describe the bytecode 
verifier because they are more precise than prose, clearer than code, and easier to 
reason about than either. 

JVML has a subroutine construct which is used for the compilation of Java's try- 
finally statement. Subroutines are a major source of complexity for the bytecode 
verifier because they are not obviously last-in/first-out and because they require a 
kind of polymorphism. Focusing on subroutines, we isolate an interesting, small 
subset of JVML. We give typing rules for this subset and prove their correctness. 
Our type system constitutes a sound basis for bytecode verification and a rational 
reconstruction of a delicate part of Sun's bytecode verifier. 
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1 Bytecode verification and typing rules 



The Java language is typically compiled into an intermediate language that is inter- 
preted by the Java Virtual Machine (VM) [LY96]. This intermediate language, which 
we call JVML, is an object-oriented language similar to Java. Its features include 
packages, classes with single inheritance, and interfaces with multiple inheritance. 
However, unlike method bodies in Java, method bodies in JVML are sequences of 
bytecode instructions. These instructions are fairly high-level but, compared to the 
structured statements used in Java, they are more compact and easier to interpret. 

JVML code is often shipped across networks to Java VMs embedded in web 
browsers and other applications. Mobile JVML code is not always trusted by the 
VM that receives it. Therefore, a bytecode verifier enforces static constraints on 
mobile JVML code. These constraints rule out type errors (such as dereferencing an 
integer), access control violations (such as accessing a private method from outside 
its class), object initialization failures (such as accessing a newly allocated object 
before its constructor has been called), and other dynamic errors. 

Figure 1 illustrates how bytecode verification fits into the larger picture of Java 
security. The figure represents trusted and untrusted code. At the base of the 
trusted code is the Java VM itself — including the bytecode verifier — plus the operat- 
ing system, which provides access to privileged resources. On top of this base layer 
is the Java library, which provides controlled access to those privileged resources. 
Java security depends on the VM correctly interpreting JVML code, which in turn 
depends on the verifier rejecting illegal JVML code. If the verifier were broken but 
the rest of the VM assumed it was correct, then JVML code could behave in ways 
not anticipated by the Java library, circumventing the library's access controls. 

For example, the current implementation of the library contains private methods 
that access privileged resources without performing access control checks. This im- 
plementation depends on the verifier preventing untrusted code from calling those 
private methods. But if the verifier were broken, an attacker might be allowed to 
treat an instance of a library class as an instance of a class defined by the attacker. 
In this situation, the class defined by the attacker could be used as a back door. At 
runtime, most VMs use dispatch-table indices to name methods. Successful invoca- 
tion of a method depends only on this index and on passing the right number and 
type of arguments to the method. If the verifier allowed the attacker to treat an 
instance of the library class as an instance of the back-door class, then the attacker 
could call the instance's methods, including the private ones that do not perform 
access control checks. 

As this example shows, a successful attack requires more than a broken verifier 
that accepts rogue JVML code. If, in our example, a VM had some runtime mech- 
anism for preventing the use of an instance of an unexpected class, then the attack 
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Figure 1: The Java VM and security 



would fail. However, this mechanism might be expensive. Thus, the purpose of 
the verifier is to permit implementations of JVML that are fast without sacrificing 
safety. The primary customer of the verifier is the rest of the VM implementation: 
instruction interpretation code, JIT-compiler routines, and other code that assumes 
that illegal input code is filtered out by the verifier. 

Given its importance for security, current descriptions of the verifier are deficient. 
The official specification of the verifier is a prose description [LY96] . Although good 
by the standards of prose, this description is ambiguous, imprecise, and hard to rea- 
son about. In addition to this specification, Sun distributes what could be considered 
a reference implementation of the verifier. As a description, this implementation is 
precise, but it is hard to understand and, like the prose description, is hard to reason 
about. Furthermore, the implementation disagrees with the prose description. 

This paper proposes using typing rules to describe the verifier. Typing rules 
are more precise than prose, easier to understand than code, and they can be ma- 
nipulated formally. Such rules would give implementors of the verifier a systematic 
framework on which to base their code, increasing confidence in its correctness. Such 
rules would also give implementors of the rest of the VM an unambiguous statement 
of what they can and cannot assume about legal JVML code. 

From a typing perspective, JVML is interesting in at least two respects: 

• In JVML, a location can hold different types of values at different program 
points. This flexibility allows locations to be reused aggressively, allowing 
interpreters to save space. Thus, JVML contrasts with most typed languages, 
in which a location has only one type throughout its scope. 

• JVML has subroutines to help compilers generate compact code, for example 
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for Java try-finally statements. JVML subroutines are subsequences of the 
larger sequence of bytecode instructions that make up a method's body. The 
JVML instruction j sr jumps to the start of one of these subsequences, and the 
JVML instruction ret returns from one. Subroutines introduce two significant 
challenges to the design of the bytecode verifier: the verifier should ensure that 
ret is used in a well-structured manner, and it should support a certain kind 
of polymorphism. We describe these challenges in more detail in Section 2. 

This paper addresses these typing problems. It defines a small subset of JVML, 
called JVMLO, presents a type system and a dynamic semantics for JVMLO, and 
proves the soundness of the type system with respect to the dynamic semantics. 
JVMLO includes only 9 instructions, and ignores objects and several other features 
of JVML. This restricted scope allows us to focus on the challenges introduced by 
subroutines. Thus, our type system provides a precise, sound approach to bytecode 
verification, and a rational reconstruction of a delicate part of Sun's bytecode verifier. 
We present the type system in three stages: 

1. The first stage is a simplified version for a subset of JVMLO that excludes jsr 
and ret. This simplified version provides an introduction to our notation and 
approach, and illustrates how we give different types to locations at different 
program points. 

2. The next stage considers all of JVMLO but uses a structured semantics for jsr 
and ret. This structured semantics has an explicit subroutine call stack for 
ensuring that subroutines are called on a last-in, first-out basis. In the context 
of this structured semantics, we show how to achieve the polymorphism desired 
for subroutines. 

3. The last stage uses a stackless semantics for jsr and ret in which return ad- 
dresses are stored in random-access memory. The stackless semantics is closer 
to Sun's. It admits more efficient implementations, but it does not dynamically 
enforce a last-in, first-out discipline on calls to subroutines. Because such a 
discipline is needed for type safety, we show how to enforce it statically. 

The next section describes JVML subroutines in more detail and summarizes 
our type system. Section 3 gives the syntax and an informal semantics for JVMLO. 
Sections 4-6 present our type system in the three stages outlined above. Section 7 
states and proves the main soundness theorem for our type system. Sections 8 and 9 
discuss related work, including Sun's bytecode verifier. Section 8 also considers how 
our type system could be extended to the full JVML. Section 10 concludes. Several 
appendices contain proofs. 
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2 Overview of JVML subroutines and our type system 



JVML subroutines are subsequences of a method's larger sequence of instructions; 
they behave like miniature procedures within a method body. Subroutines are used 
for compiling Java's try- finally statement. 

Consider, for example, the Java method named bar at the top of Figure 2. 
The try body can terminate in one of three ways: immediately when i does not 
equal 3, with an exception raised by the call to foo, or with an execution of the 
return statement. In all cases, the compiler must guarantee that the code in the 
finally block is executed when the try body terminates. Instead of replicating the 
finally code at each escape point, the compiler can put the finally code in a JVML 
subroutine. Compiled code for an escape from a try body executes a jsr to the 
subroutine containing the finally code. 

Figure 2 illustrates the use of subroutines for compiling try-finally statements. 
It contains a possible result of compiling the method bar into JVML, putting the 
finally code in a subroutine in lines 13-16. 

Figure 2 also introduces some of JVML's runtime structures. JVML bytecode 
instructions read and write three memory regions. The first region is an object heap 
shared by all method activations; the heap does not play a part in the example 
code of Figure 2. The other two regions are private to each activation of a method. 
The first of these private regions is the operand stack, which is intended to be used 
on a short-term basis in the evaluation of expressions. For example, the instruction 
iconst_3 pushes the integer constant 3 onto this stack, while ireturn terminates the 
current method and returns the integer at the top of the stack. The second private 
region is a set of locations known as local variables, which are intended to be used on 
a longer-term basis to hold values across expressions and statements (but not across 
method activations). Local variables are not operated on directly. Rather, values in 
local variables are pushed onto the stack and values from the stack are popped into 
local variables via the load and store instructions respectively. For example, the 
instruction aloacLO pushes the object reference in local variable 0 onto the operand 
stack, while the instruction istore_2 pops the top value off the operand stack and 
saves it in local variable 2. 

Subroutines pose two challenges to the design of a type system for JVML: 

• Polymorphism. Subroutines are polymorphic over the types of the locations 
they do not touch. For example, consider how variable 2 is used in Figure 2. At 
the j sr on line 7, variable 2 contains an integer and is assumed to contain an 
integer when the subroutine returns. At the jsr on line 18, variable 2 contains 
a pointer to an exception object and is assumed to contain a pointer to an 
exception object when the subroutine returns. Inside a subroutine, the type 
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int bar(int i) { 
try { 

if (i == 3) return this.fooO; 
} finally { 

this.ladidaO ; 

} 

return i; 

} 



01 iload_l // Push i 

02 iconst_3 // Push 3 

03 if_icmpne 10 // Goto 10 if i does not equal 3 
// Then case of if statement 

04 aload_0 // Push this 

05 invokevirtual foo // Call this.foo 

06 istore_2 // Save result of this.fooO 

07 jsr 13 // Do finally block before returning 

08 iload_2 // Recall result from this.fooO 

09 ireturn // Return result of this.fooO 
// Else case of if statement 

10 jsr 13 // Do finally block before leaving try 
// Return statement following try statement 

11 iload_l // Push i 

12 ireturn // Return i 
// finally block 

13 astore_3 // Save return address in variable 3 

14 aload_0 // Push this 

15 invokevirtual ladida // Call this.ladidaO 

16 ret 3 // Return to address saved on line 13 
// Exception handler for try body 

17 astore_2 // Save exception 

18 jsr 13 // Do finally block 

19 aload_2 // Recall exception 

20 athrow // Rethrow exception 
// Exception handler for finally body 

21 athrow // Rethrow exception 

Exception table (maps regions of code to their exception handlers) : 

Region Target 
1-12 17 
13-16 21 



Figure 2: Example compilation of try-finally into JVML 
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// Assume variable 0 contains pointer to this 


01 


iconst_l 


// 


Push 1 


02 


istore_l 


// 


Initialize variable 1 to 1 


03 


jsr 13 


// 


Call subroutine 


04 


aloacLO 


// 


Push this 


05 


iconst_0 


// 


Push 0 


06 


putfield x 


// 


Set this.x to 0 


07 


iconst_l 


// 


Push 1 


08 


istore_0 


// 


Set variable 0 to 1 


09 


iconstJD 


// 


Push 0 


10 


istore_l 


// 


Set variable 1 to 0 


11 


jsr 13 


// 


Call subroutine 


12 


return 


// 


End of method 




// Top of subroutine 


13 


iloacLl 


// Push variable 1 


14 


iconst_0 


// 


Push 0 


15 


if_icmpeq 18 


// 


Goto 18 if variable 1 equals 0 


16 


astore_2 


// 


Save return address in variable 2 


17 


ret 2 


// 


Return to return address in variable 2 


18 


pop 


// 


Throw out current return address 


19 


ret 2 


// Return to old address saved in variable 2 



Figure 3: Illegal JVML code 

of a location such as variable 2 can depend on the call site of the subroutine. 
(Subroutines are not parametric over the types of the locations they touch; the 
polymorphism of JVML is thus weaker than that of ML.) 

• Last-in, first-out behavior. In most languages, when a return statement in 
procedure P is executed, the dynamic semantics guarantees that control will 
return to the point from which P was most recently called. The same is not 
true of JVML. The ret instruction takes a variable as a parameter and jumps 
to whatever address that variable contains. This semantics means that, unless 
adequate precautions are taken, the ret instruction can transfer control to 
almost anywhere. 

Using ret to jump to arbitrary places in a program is inimical to static typing, 
especially in the presence of polymorphism. For example, consider the illegal JVML 
method body in Figure 3. This method body has two calls to the subroutine that 
starts at line 13, which is polymorphic over variable 0. The first time this subroutine 
is called, it stores the return address into variable 2 and returns. The second time 
this subroutine is called, it returns to the old return address stored away in variable 2. 
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This causes control to return to line 4, at which point the code assumes that variable 0 
contains a pointer. However, between the first and second calls to the subroutine, an 
integer has been stored into variable 0. Thus, the code in Figure 3 will dereference 
an integer. 

Our type system allows polymorphic subroutines and enforces last-in, first-out 
behavior. It consists of rules that relate a program (a sequence of bytecode instruc- 
tions) to static information about types and subroutines. This information maps 
each memory location of the VM to a type at each program point, identifies the 
instructions that make up subroutines, indicates the variables over which subrou- 
tines are polymorphic, and gives static approximations to the dynamic subroutine 
call stack. 

Our type system guarantees the following properties for well-typed programs: 

• Type safety. An instruction will never be given an operand stack with too few 
values in it, or with values of the wrong type. 

• Program counter safety. Execution will not jump to undefined addresses. 

• Bounded operand stack. The size of the operand stack will never grow beyond 
a static bound. 

3 Syntax and informal semantics of JVMLO 

In JVMLO, our restricted version of JVML, a program is a sequence of instructions: 

P ::= instruction* 

We treat programs as partial maps from addresses to instructions. We write Addr 
for the set of all addresses. Addresses are very much like positive integers, and we use 
the constant 1 and the function + on addresses. However, to provide more structure 
to our semantics, we treat numbers and addresses as separate sets. When P is a 
program, we write Dom(P) for the domain of P (its set of addresses); P[i] is defined 
only for i 6 Dom{P). We assume that 1 6 Dom(P) for every program P. 

In JVMLO, there are no classes, methods, or objects. There is no object heap, 
but there is an operand stack and a set of local variables. We write Var for the set 
of names of local variables. (In JVML, these names are actually natural numbers, 
but we do not require this.) Local variables and the operand stack both contain 
values. A value is either an integer or an address. 
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JVMLO has only 9 instructions: 



instruction ::= inc | pop | pushO 



load x | store x 
if L 

jsr L | ret x 
halt 



where x ranges over Var, and L ranges over Addr. Informally, these instructions 
behave as follows: 

• The inc instruction increments the value at the top of the operand stack if 
that value is an integer. The pop instruction pops the top off the operand 
stack. The pushO instruction pushes the integer 0 onto the operand stack. 

• The load x instruction pushes the current value of local variable x onto the 
operand stack. The store x instruction pops the top value off the operand 
stack and stores it into local variable x. 

• The if L instruction pops the top value off the operand stack and either falls 
through when that value is the integer 0 or jumps to L otherwise. 

• At address p, the jsr L instruction jumps to address L and pushes return 
address p + 1 onto the operand stack. The ret x instruction jumps to the 
address stored in x. 

• The halt instruction halts execution. 

4 Semantics without subroutines 

This section introduces our approach and some notation. It presents static and 
dynamic semantics for the subset of JVMLO that excludes jsr and ret. 

We use (partial) maps extensively throughout this paper. When g is a map, 
Dom(g) is the domain of g; for x € Dom(g), g[x] is the value of g at x, and g[x t— > v] 
is the map with the same domain as g defined by the following equation, for all 
y G Dom(g): 



That is, g[x ^ v] has the same value as g at all points except x, where g[x t— > v] has 
value v. We define equality on maps as follows: 




x^y 
x = y 



f = g = Dom(f) = Dom(g) A Vx 6 Dom(f). f[x] = g[x] 
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That is, / = g exactly when / and g have the same domains and have equal values 
at all points. 

We often use maps with domain Addr. We call those maps vectors. When F is 
a vector and i is an address, we may write F{ instead of F[i\. 

We also use strings. The constant e denotes the empty string. If s is a string, 
then v ■ s denotes the string obtained by prepending v to s. Sometimes we treat 
strings as maps from indices to integers. Then Dom(s) is the set of indices of s, and 
s[i] is the zth element of s from the right. Concatenation adds a new index for the 
new element but does not change the indices of the old elements; that is: 

Vs, i,n. i G Dom(s) 4> i G Dom{n ■ s) A (re • s)[i] = s[i] 
4.1 Dynamic semantics 

We model a state of an execution as a tuple (pc, f, s), where pc is the program 
counter, / is the current state of local variables, and s is the current state of the 
operand stack. 

• The program counter pc is an address, that is, an element of Addr. 

• The current state of local variables / is a total map from Var to the set of 
values. 

• The current state of the stack s is a string of values. 

All executions start from states of the form (1, /, e), where / is arbitrary and where 
e represents the empty stack. 

Figure 4 contains a small-step operational semantics for all instructions other 
than jsr and ret. This semantics relies on the judgment 

P h {pc, f, s) -> (pc', /', s') 

which means that program P can, in one step, go from state (pc, f, s) to state 
(pd , f, s f ). By definition, the judgment P h (pc, f, s) — > (pc 1 , /', s') holds only 
when P is a program and (pc, f, s) and (pc', f, s') are states. In Figure 4 (and in 
the rest of this paper), n matches only integers while v matches any value. Thus, 
for example, the pattern "re • s" represents a non-empty stack whose top element 
is an integer. Note that there is no rule for halt — execution stops when a halt 
instruction is reached. Execution may also stop as the result of a dynamic error, for 
example attempting to execute a pop instruction with an empty stack. 
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P[pc] — inc 
Ph(pc, f,n-s)^(pc+l,f, (n+l)-s) 

P[pc] = pop P[pc] = pushO 



P h (pc, /, v ■ a) - (pc+ 1, /, a) P h (pc, /, s) - (pc+ 1, /, 0 • s) 

P[pc] — load x P[pc] = store x 

P \- (pc, f, s) -> (pc+ 1, /, /[or] • s) P\- (pc, f,v-s) -> (pc+ 1, /[x u], s) 

- if ^ Pbc J: 0 ifL 

Ph(pc, /, 0-s)-<pc+l, /, a) 



P I" (pc, /, n ■ s) -» (L, /, s) 

Figure 4: Dynamic semantics without j sr and ret 
4.2 Static semantics 

Our static semantics employs the following typing rules for values: 
v is a value n is an integer K, L are addresses 



v : Top n : Int if : (ret-from L) 

The type Top includes all values. The type Int is the type of integers. Types of the 
form (ret-from L) include all addresses. However, the typing rules for programs 
of Sections 5 and 6 make a more restricted use of address types, preserving strong 
invariants. As the syntax (ret-from L) suggests, we use L as the name for the 
subroutine that starts at address L, and use (ret-from L) as the type of return 
addresses generated when L is called. Collectively, we refer to the types Top, Int, 
and (ret-from L) as value types. 

Types are extended to stacks as follows: 

(Empty hypothesis) v :T s : a 



v • s :T • a 



where T is a value type and a is a string of value types. The empty stack is typed 
by the empty string; a stack with n values is typed by a string with n types, each 
type correctly typing the corresponding value in the string of values. 

A program is well-typed if there exist a vector F of maps from variables to types 
and a vector S of strings of types satisfying the judgment: 

F,S h P 
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P[i\ = if L 
Fi+i = Fl = Fi 

Si = INT • S i+ i = INT • S L 

i + le Dom(P) 
L e Dom{P) 
F~SJV P 

P[i] = pushO 
Fi+i = Fi 

S i+1 = INT • Si 

i + le Dom(P) 
F,S,i\- P 

P[i] = store x 
x e Dom(Fi) 
F l+1 = F t [x^T] 
Si = T ■ Si+i 
i + le Dom(P) 
F,S,ihP 

P[i] = halt 
F~SJFP 



Figure 5: Static semantics without j sr and ret 

The vectors F and S contain static information about the local variables and operand 
stack, respectively. The map Fi assigns types to local variables at program point i. 
The string Si gives the types of the values in the operand stack at program point i. 
(Hence the size of Si gives the number of values in the operand stack.) For notational 
convenience, the vectors F and S are defined on all of Addr even though P is not; 
Fj and Sj are dummy values for out-of-bounds j. 
We have one rule for proving F,S h P: 

Fi=£ 

Si=€ 

Vj £ DomjP). F,S,ih P 
F,S\-P 

where £ is the map that maps all variables to Top and e is (as usual) the empty 
string. The first two hypotheses are initial conditions; the third is a local judgment 
applied to each program point. Figure 5 has rules for the local judgment F,S,i\- P. 



P[i] = inc 
Fi+i = Fi 
Sj+i = Si = Int • a 
i + le Dom(P) 
F~SJV P 

P[i] = pop 
Fi+i = Fi 
Si = T ■ Si+i 
i + le Dom(P) 
F,S,i\- P 

P[i] = load x 
x e Dom{Fi) 
Fi+i = Fi 
S i+ i = Fi[x] ■ Si 
i + le Dom(P) 
F,S,i\- P 
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These rules constrain F and S at point i by referring to Fj and Sj for all points j 
that are control-flow successors of i. 

4.3 One-step soundness theorem 

The rules above are sound in that any step from a well-typed state leads to another 
well-typed state: 

Theorem 1 For all P, F, and S such that F,Sh P: 

Vpc, f,s,pd,s',f. 

A P h (pc, f, s) - (pc/, /', s') 
A Vy. /[y] : F pc [y] 
A s : S'pc 
^J-.SpffAVy. f[y\:Fp C [y\ 

We do not prove this theorem, but we do prove similar theorems for programs in- 
cluding jsr and ret. (See the appendices.) 

5 Structured semantics 

This section shows how to handle jsr and ret with the kind of polymorphism 
described in Section 2. To isolate the problem of polymorphism from the problem of 
ensuring that subroutines are used in a well-structured manner, this section presents 
what we call the structured semantics for JVMLO. This semantics is structured 
in that it defines the semantics of jsr and ret in terms of an explicit subroutine 
call stack. This section shows how to achieve polymorphism in the context of the 
structured semantics. The next section shows how to ensure that subroutines are 
used in a well-structured manner in the absence of an explicit call stack. 

5.1 Dynamic semantics 

In the structured semantics, we augment the state of an execution to include a 
subroutine call stack. This call stack holds the return addresses of subroutines that 
have been called but have not yet returned. We model this call stack as a string p 
of addresses. Thus, the state of an execution is now a four-tuple {pc, f, s, p). 

Figure 6 defines the structured dynamic semantics of JVMLO. The rules of 
Figure 6 use the subroutine call stack to communicate return addresses from jsr 
instructions to the corresponding ret instructions. Although ret takes an operand 
x, the structured dynamic semantics ignores this operand; similarly, the structured 
dynamic semantics of j sr pushes the return address onto the operand stack as well as 
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P[pc] = inc 

P h, (pc, f, n- s, p) -> (pc + 1, /, (n + 1) • s, p) 

P[pc] = pop 

P h s (pc, /, u ■ s, p) -> (pc + 1, /, s, p) 

P[pc] = push.0 
P h s (pc, /, s, p) -> (pc+ 1, /, 0 • s, p) 

P [pc] = load a; 
P h (pc, /, s, p) -> (pc+ 1, /, f[x] ■ s, p) 

P[pc] = store x 
P h (pc, f,v-s,p)-> (pc+ 1, f[x i ^ u], s, p) 

P[pc] = if_L 

P h (pc, /, 0 • s, p) -> (pc+ 1, /, s, p) 

P[pc] = if L 
0 

P K (pc, /, n • s, p) -> (L, /, s, p) 

P[pc] = jsr £ 

P K (pc, /, s, p) -> (L, /, (pc+ 1) • s, (pc+ 1) • p) 

P[pc] = ret a; 
P \- s (pc, f, s, pc' ■ p) -> (pc', /, s, p) 

Figure 6: Structured dynamic semantics 

onto the subroutine call stack. These definitions enable us to transfer the properties 
of the structured semantics of this section to the stackless semantics of the next 
section. 

5.2 Static semantics 

The structured static semantics relies on a new typing judgment: 

F,ShP 
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This judgment is denned by the rule: 



Fi = £ 
Si = e 

Ri = {} 
Vi € Dom(P). R,i\- P labeled 
Vi 6 Dom(P). F,S,ih P 

F,S\- a P 

The new, auxiliary judgment 

R,i\- P labeled 

is used to define what it means to be "inside" a subroutine. Unlike in most lan- 
guages, where procedures are demarcated syntactically, in JVMLO and JVML the 
instructions making up a subroutine are identified by constraints in the static se- 
mantics. For the instruction at address i, Ri is a subroutine label that identifies the 
subroutine to which the instruction belongs. These labels take the form of either 
the empty set or a singleton set consisting of an address. If an instruction's label 
is the empty set, then the instruction belongs to the top level of the program. If 
an instruction's label is the singleton set {L}, then the instruction belongs to the 
subroutine that starts at address L. Figure 7 contains rules for labeling subroutines. 
These rules do not permit subroutines to have multiple entry points, but they do 
permit multiple exits. 

For some programs, more than one R may satisfy both R\ = {} and the con- 
straints of Figure 7 because the labeling of unreachable code is not unique. It is 
convenient to assume a canonical R for each program P, when one exists. (The 
particular choice of R does not matter.) We write Rp for this canonical R, and Rp t i 
for the value of Rp at address i. 

Much as in Section 5, the judgment 

F, S,i\- a P 

imposes local constraints near program point i. For the instructions considered in 
Section 5 (that is, for all instructions but jsr and ret), the rules are the same as in 
Figure 5. Figure 8 contains rules for jsr and ret. 

The elements of F need not be defined on all variables. For an address i inside 
a subroutine, the domain of Fj includes only the variables that can be read and 
written inside that subroutine. The subroutine is polymorphic over variables outside 
Dom(Fi). 

Figure 9 gives an example of polymorphism. (Simpler examples could be found 
if the typing rules allowed a more liberal use of Top.) The code, in the rightmost 
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P[i] € {inc, pop, pushO, load a;, store x} 

Rj+i = Ri 

R,i\- P labeled 

P[i] = if L 
Rj+i = Rl = Ri 
R,i\- P labeled 

P[i\ = jsri 

Ri+l = Ri 

Rl = {L} 
R,i\- P labeled 

P[i] e {halt, ret x} 
RjY- P labeled 

Figure 7: Rules labeling instructions with subroutines 



P[i] = jsr L 
Dom{F i+1 ) = Dom{Fi) 
Dom(F L ) C Dom(Fi) 
Vy € £>om(Fi)\£>om(F L ). = 
Vy€^ 0 m( J F L ).F L [y] = F l [y] 
5l = (ret-f rom L) ■ Si 
i + le Dom(P) 

L g Dom(P) 

F,S,i\- a P 

P[i) = ret x 
Rp, = {L} 

Vj. P\j] = jsr L => f A V / e = ^ ) 

F,S,i\-„ P 



Figure 8: Structured static semantics for jsr and ret 
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Figure 9: Example of typing 

column of Figure 9, computes the number 2 and leaves it at the top of the stack. 
The code contains a main body and three subroutines, which we have separated with 
horizontal lines. The subroutine that starts at line 6 increments the value in variable 
0. The subroutine that starts at line 11 also increments the value in variable 0 but 
leaves its result on the stack. These subroutines are implemented in terms of the 
one that starts at line 15, which increments the value at the top of the stack. This 
last subroutine is polymorphic over variable 0. 

5.3 One-step soundness theorem 

To state the one-step soundness theorem for the structured semantics, two definitions 
are needed. 

In the previous section, where programs do not have subroutines, the type of 
local variable x at program point pc is denoted by Fp C [x]. However, for program 
points inside subroutines, this definition is not quite adequate. For x 6 Dom(Fp C ), 
the type of x is still Fp C [x\. For other x, the type of x depends on where execution 
has come from. A subroutine is polymorphic over local variables that are not in 
Dom(Fp C ): different call sites of the subroutine may have values of different types 
in those local variables. Therefore, we construct an assignment of types to local 
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variables that takes into account where execution has come from. The expression: 



F{F,pc, p)[x] 

denotes the type assigned to local variable x when execution reaches point pc with 
a subroutine call stack p. The type T{F,pc, p)[x\ is defined by the rules: 

x £ Dom(Fpc) 
F(F,pc,p)[x]=F pc [x] {tt ° } 

x 0 Dom(Fpc) 
F{F,p,p)[x]=T (ttl) 



F(F,pc,p-p)[x]=T 

Note that J-{F, pc, p) [x] is not defined when x is not in Dom{F p C ) or any of the 
Dom(Fp) for the p's in p. However, the theorems and lemmas in the following 
subsections consider only situations in which T is defined. 

The second auxiliary definition for our theorem concerns an invariant on the 
structure of the subroutine call stack. The theorem of the previous section says 
that, when a program takes a step from a well-typed state, it reaches a well-typed 
state. With subroutines, we need to assume that the subroutine call stack of the 
starting state is well-formed. For example, if the address p is in the call stack, 
then it must be the case that the instruction at p — 1 is a jsr instruction. The 
new theorem says that if the program takes a step from a well-typed state with a 
well-formed subroutine call stack, then it reaches a well-typed state with a well- 
formed subroutine call stack. The following judgment expresses what we mean by a 
well-formed subroutine call stack: 

WFCallStack{P, F, pc, p) 

This judgment is defined by the rules: 

Dom ( F Pc) = (wf0) 

WFCallStack(P,F,pc,e) 

P]p-1] = jsr L 
L 6 Rp^pc 

Dom(Fp C ) C Dom(F p ) (wf 1) 

WFCallStack(P,F,p, p) 



WFCallStack{P, F, pc,p ■ p) 
Informally, a subroutine call stack p is well-formed when: 
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• given a return address p in p, the instruction just before p is a j sr instruction 
that calls the routine from which p returns; 

• the current program counter pc and all return addresses in p have the correct 
subroutine label associated with them; 

• the return address at the bottom of the call stack is for code that can access 
all local variables; 

• any variable that can be read and written by a callee can also be read and 
written by its caller. 

With these two definitions, we can state a one-step soundness theorem for the 
structured semantics. The proof of this theorem is in Appendix A. 

Theorem 2 For all P, F, and S such that F, S h s P: 

Vpc, f,s,p,pd,f,s',p'. 

A P h (pc, f, s, p) - (pc', f, s', p') 
A WFCallStack(P, F, pc, p) 
A Vy.3T.T(F,pc,p)[y} = T A f[y] : T 
A s : S pc 

=> 

A WFCallStack{P,F,pc',p') 

A Vy. 3T'. T{F, pc' , p')[y) = T> A f'[y] : T 

A s' : Sp C > 

6 Stackless semantics 

The remaining problem is to eliminate the explicit subroutine call stack of the pre- 
vious section, using instead the operand stack and local variables to communicate 
return addresses from a jsr to a ret. As discussed in Section 2, when the semantics 
of jsr and ret are defined in terms of the operand stack and local variables, uncon- 
trolled use of ret combined with the polymorphism of subroutines is inimical to type 
safety. This section presents a static semantics that rules out problematic uses of 
ret. This static semantics restricts programs to operate as if an explicit subroutine 
call stack like the one from the previous section were present. In fact, the soundness 
argument for the stackless semantics relies on a simulation between the structured 
semantics and the stackless semantics. 

The static and dynamic semantics described in this section are closest to typical 
implementations of JVML. Thus, we consider these the official semantics of JVMLO. 
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P[pc] = jsr L 
P\-(pc,f,s)^(L,f, (pc+l)-s) 

P[pc] = ret x 
PV- {pc, f, s)^(f[x], /, s) 

Figure 10: Stackless dynamic semantics for jsr and ret 

6.1 Dynamic semantics 

The stackless dynamic semantics consists of the rules of Figure 4 plus the rules 
for jsr and ret of Figure 10. The jsr instruction pushes the return address onto 
the operand stack. To use this return address, a program must first pop it into 
a local variable and then reference that local variable in a ret instruction. The 
ret x instruction extracts an address from local variable x; if x does not contain an 
address, then the program gets stuck (because (f[x], f, s) is not a state). 

6.2 Static semantics 

To define the stackless static semantics, we revise the rule for F, S h P of Section 4. 
The new rule is: 

Fi = S 
Si = e 
Ci = e 

Vi G Dom(P). C,i\- P strongly labeled 

Vt £ DomjP). F,S,ih P 

F,S\~ P 

The new, auxiliary judgment 

C, z h P strongly labeled 

constrains C to be an approximation of the subroutine call stack. Each element of C 
is a string of subroutine labels. For each address i, the string d is a linearization of 
the subroutine call graph to i. Of course, such a linearization of the subroutine call 
graph exists only when the call graph is acyclic, that is, when subroutines do not 
recurse. (We believe that we can prove our theorems while allowing recursion, but 
disallowing recursion simplifies our proofs and agrees with Sun's specification [LY96, 
p. 124].) Figure 11 contains the rules for this new judgment; note that a subsequence 
is not necessarily a consecutive substring. Figure 12 shows an application of the rules 
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P[i] € {inc, pop, pushO, load x, store x} 

= Cj 

C,ihP strongly labeled 

p\i\ = if l 

Cj+i = C l = Ci 
C,i\- P strongly labeled 

P[i\ = jsri 
£^C 4 
Cj+i = Ci 
C L - L • c 
Ci is a subsequence of c 
C,i\- P strongly labeled 

P[i] e {halt, ret x} 
C,i\- P strongly labeled 

Figure 11: Rules approximating the subroutine call stack at each instruction 
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Figure 12: Example of C labeling 
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P[i] = jsr L 
Dom{F l+1 ) = Dom(Fi) 
Dom(F L ) C Dom(Fi) 
Vy e £om(F,)\.Dom(F L ). = F^y] 

y y eDom(F L ).F L [y} = F l [y} 
Sl — (ret-f rom L) ■ Si 
(ret-f rom L) £ Si 
Vy e Dom(F L ). F L [y] ^ (ret-from L) 
i + 1 e Dom(P) 

L £ Dom(P) 

F,S,i\- P 



P[i] — ret x 

Rp,i = {L} 
x € Dom(Fi) 
Fi[x] = (ret-from L) 

Vj. P\j] = jsr L ^ ( A A l y S D T iFt) - Fl+M = FM ) 

\ A bj+l = Si £ 



Figure 13: Stackless static semantics for jsr and ret 



of Figure 11 to the code from Figure 9. In this example, the order of 6 and 11 could 
be reversed in C15, Ci6, and C17. 

As with R, more than one C may satisfy both C\ = e and the constraints in 
Figure 11. We assume a canonical C for each program P, when one exists. We write 
Cp for this canonical C, and Cp^ for the value of Cp at address i. Programs that 
satisfy the constraints in Figure 11 also satisfy the constraints in Figure 7; we define 
Rp from Cp as follows: 




{} when Cp^ = e 

{L} when Cp t i = L ■ c for some c 



On the other hand, programs with recursive subroutines may satisfy the constraints 
in Figure 7 but never those in Figure 11. 

Figure 13 contains the rules that define F,S,i h P for jsr and ret; rules for 
other instructions are in Figure 5. The rule for jsr L assigns the type (ret-from L) 
to the return address pushed onto the operand stack. This type will propagate to any 
location into which this return address is stored, and it is checked by the following 



21 



hypotheses in the rule for ret: 

x 6 Dom(Fi) 
Fi[x] = (ret-from L) 

Typing return addresses helps ensure that the return address used by a subroutine L 
is a return address for L, not for some other subroutine. By itself, ensuring that the 
return address used by a subroutine L is a return address for L does not guarantee 
last-in, first-out behavior. One also has to ensure that the only return address for L 
available inside L is the most recent return address, not one tucked away during a 
previous invocation. This is achieved by the following hypotheses in the rule for jsr: 

(ret-from L) g" Si 
Vy G Dom{F L ). F L [y] ^ (ret-from L) 

These hypotheses guarantee that the only value of type (ret-from L) available 
inside L is the most recent value of this type pushed by the j sr instruction. (These 
hypotheses might be redundant for reachable code; we include them because our 
rules apply also to unreachable code.) Except for the lines discussed above, the 
rules for jsr and ret are the same as those of the structured static semantics. As 
an example, we may simply reuse the one of Figure 9, since the typing given there 
remains valid in the stackless static semantics. 

6.3 One-step soundness theorem 

The one-step soundness theorem for the stackless semantics requires some auxiliary 
definitions. We develop those definitions top-down, after stating the theorem. The 
proof of the theorem is in Appendix B. 

Theorem 3 For all P, F, and S such that F,Sh P: 

Vpc, f,s,p,pc',f,s'. 

A P h (pc, f, s) - (pd, /', s') 
A Consistent(P, F, S, pc, f, s, p) 
A Vy. 3T.T(F,pc,p)[y] = T A f[y] : T 
A s : S pc 
=> 3p'. 

A Consistent F, S, pc', /', s', p') 

A Vy. 3T'. F(F, pd , p')[y] = T> A f'[y] : V 

A s' : Sp C ' 

In this theorem, the judgment Consistent performs several functions: 
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• Like WFCallStack in the one-step soundness theorem for the structured se- 
mantics, Consistent implies an invariant on the structure of the subroutine call 
stack. 

• In the stackless semantics, the subroutine call stack is not explicit in the dy- 
namic state. The judgment Consistent relates an implicit subroutine call stack 
(p or p') to the state of an execution. 

• The implicit subroutine call stacks of the stackless semantics are closely related 
to the explicit subroutine call stacks of the structured semantics. In particular, 
the following implication holds: 

Vpc, f,s,p,pd,f,s'. 

A P h (pc, f, s) - (pd, /', s') 
A Consistent(P, F, S, pc, f, s, p) 
3p'. P h {pc, f, s, p) -> {pc', f, s', p') 

Thus, Consistent helps us relate the structured and the stackless semantics. 

The judgment Consistent is the conjunction of four other judgments: 

ConsistentiP, F, S, pc, f, s, p) = 
A WFCallStack(P, F, pc, p) 
A WFCallStack2{P,pc,K P {p),p) 
A GoodStackRets(Sp C , s, Ap(p), p) 
A GoodFrameRets(F , pc, {}, f,kp(p),p) 

The first judgment is the judgment WFCallStack from the previous section. The 
next judgment adds more constraints on the subroutine call stack. The last two 
judgments constrain the values of return addresses in s (the operand stack) and / 
(local variables) to match those found in p (the implicit subroutine call stack). 

The auxiliary function A returns the sequence of caller labels associated with a 
sequence of return addresses. It is a partial function defined by two rules: 

(Empty hypothesis) 
A P (e) = e 

P\p- 1] = j sr L 

Ap(p') = X' (11) 
A P (p ■ p') = L ■ X' 

According to this definition, Ap(p) is the string of labels of subroutines that have 
been called in p. The function Ap(p) is used only when P is well-typed and 
WFCallStack holds, in which case Ap(p) is always defined. 
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The extensions of WFCallStack made by WFCallStack2 are denned by two rules: 

°P,PC = e fufOOl 

WFCallStack2{P, pc, e, e) 

L ■ X' is a subsequence of Cp t p C 

WFCallStack2{P,p,X',p r ) ( } 



WFCallStack2{P, pc, L-X',p- p') 

These rules ensure that no recursive calls have occurred. They also ensure that 
the dynamic subroutine call stack is consistent with the static approximation of the 
subroutine call stack. 

The judgment GoodStackRets constrains the values of return addresses in the 
operand stack: 

\/j,L.j 6 Dom(a) A a[j] = (ret-from L) =4> GoodRet(L, s[j], X, p) ^ ^ 



GoodStackRets(a, s, X, p) 

(Empty hypothesis) 
GoodRet(K,p, e, e) 

(Empty hypothesis) 
GoodRet(K, p, K ■ X,p ■ p) 



(grO) 
(grl) 



K' / K 

GoodRet(K,p,X',p') (gr2) 



GoodRet(K,p, K' ■ X',p' ■ p') 

In these definitions, we introduce GoodRet as an auxiliary judgment. These defi- 
nitions say that, when a subroutine L has been called but has not returned, the 
values of return addresses for L found in s (the operand stack) agree with the return 
address for L in p (the implicit subroutine call stack). 

Similarly to the judgment GoodStackRets, the judgment GoodFrameRets con- 
strains the values of return addresses in local variables: 

(Empty hypothesis) ( f 0) 



GoodFrameRets{F , pc, p, f, e, e) 



GoodFrameRets{F ,p, Dom(Fp C ), f, A', p') 
GoodFrameRets(F , pc, p, f,K ■ X',p ■ p') 
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Because subroutines may not be able to read and write all variables, GoodFrameRets 
cannot constrain all variables simultaneously in the way that GoodStackRets con- 
strains all elements of the operand stack. Instead, the rules for GoodFrameRets 
must work inductively on the subroutine call stack, looking at the return addresses 
available to each subroutine in turn. 

7 Main soundness theorem 

Our main soundness theorem is: 

Theorem 4 For all P, F, and S such that F,Sh P: 



This theorem says that if a computation stops, then it stops because it has reached 
a halt instruction, not because the program counter has gone out of bounds or 
because a precondition of an instruction does not hold. This theorem also says that 
the operand stack is well-typed when a computation stops. This last condition is 
important because, when a JVML method returns, its return value is on the operand 
stack. 

The proof of the main soundness theorem is in Appendix C. 

8 Sun's rules 

Sun has published two descriptions of the bytecode verifier, a prose specification 
and a reference implementation. This section compares our rules with both of these 
descriptions. 

8.1 Scope 

While our rules simply check static information, Sun's bytecode verifier infers that 
information. Inference may be important in practice, but only checking is crucial 
for type safety (and for security). It is therefore reasonable to study checking apart 
from inference. 

JVML has around 200 instructions, while JVMLO has only 9. A rigorous treat- 
ment of most of the remaining JVML instructions should pose only minor problems. 



Vpc,f 0 ,f,s. 



( A P h (1, f 0 , e) -* (pc, f, s) 

\ A lpd,f',st. P h {pc, f, s) - {pd, /', s 1 ) 



=>■ P[pc] = halt A s : S pc 
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In particular, many of these instructions are for well understood, arithmetic opera- 
tions; small difficulties may arise because of their exceptions and other idiosyncrasies. 
The other instructions (around 20) concern objects and concurrency. Their rigor- 
ous treatment would require significant additions to our semantics — for example, a 
model of the heap. Fortunately, some of these additions are well understood in the 
context of higher-level, typed languages. As discussed below, Freund and Mitchell 
are currently extending our rules to a large subset of JVML. 

8.2 Technical differences 

Our rules differ from Sun's reference implementation in the handling of recursive 
subroutines. Sun's specification disallows recursive subroutines, as do our rules, but 
Sun's reference implementation allows recursion in certain cases. We believe that 
recursion is sound in the sense that it does not introduce security holes. However, 
recursion is an unnecessary complication since it is not useful for compiling Java. 
Therefore, we believe that the specification should continue to disallow recursion and 
that the reference implementation should be corrected. 

Our rules deviate from Sun's specification and reference implementation in a few 
respects. 

• Sun's rules forbid load x when x is uninitialized or holds a return address. 
Our rules are more general without compromising soundness. 

• Sun's rules allow at most one ret instruction per subroutine, while our rules 
allow an arbitrary number. 

• According to Sun's rules, "each instruction keeps track of the list of j sr targets 
needed to reach that instruction" [LY96, p. 135]. Using this information, Sun's 
rules allow a ret to return not only from the most recent call but also from calls 
further up the subroutine call stack. Adding this flexibility to our rules should 
not be difficult, but it would complicate the structured dynamic semantics and 
would require additional information in the static semantics. 

Finally, our rules differ from Sun's reference implementation on a couple of other 
points. Sun's specification is ambiguous on these points and, therefore, does not 
provide guidance. 

• Sun's reference implementation does not constrain unreachable code. Our rules 
put constraints on all code. Changing our rules to ignore unreachable code 
would not require fundamental changes. 
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• When it comes to identifying what subroutine an instruction belongs to, our 
rules are more restrictive than the rules implicit in Sun's reference implementa- 
tion. The flexibility of Sun's reference implementation is important for compil- 
ing finally clauses that can throw exceptions. Changing our rules to capture 
Sun's approach would not be difficult, but changing our soundness proof to 
support this approach may be. 

9 Other related work 

In addition to Sun's, there exist several implementations of the bytecode verifier. 
Only recently has there been any systematic attempt to understand all these imple- 
mentations. In particular, the Kimera project has tested several implementations, 
pointing out some mistakes and discrepancies [SMB97]. We take a complementary 
approach, based on rigorous reasoning rather than on testing. Both rigorous rea- 
soning and testing may affect our confidence in bytecode verification. While testing 
does not provide an adequate replacement for precise specifications and proofs, it is 
a cost-effective way to find certain flaws and oddities. 

More broadly, there have been several other implementations of the Java VM. Of 
particular interest is a partial implementation developed at Computational Logic, 
Inc. [Coh97]. This implementation is defensive, in the sense that it includes strong 
(and expensive) dynamic checks that remove the need for bytecode verification. The 
implementation is written in a formal language, and is intended as a model rather 
than for production use. Ultimately, one may hope to prove that the defensive 
implementation is equivalent to an aggressive implementation plus a sound bytecode 
verifier (perhaps one based on our rules). 

There have also been typed intermediate languages other than JVML. Several 
have been developed for ML and Haskell [TIC97]. Here we discuss the TIL inter- 
mediate languages [Mor95, MTC + 96] as representative examples. The TIL inter- 
mediate languages provide static guarantees similar to those of JVML. Although 
these languages have sophisticated type systems, they do not include an analogue 
to JVML subroutines; instead, they include constructs as high-level as Java's try- 
finally statement. Therefore, the main problems addressed in this paper do not 
arise in the context of TIL. 

Finally, the literature contains many proofs of type soundness for higher-level 
languages, and in particular proofs for a fragment of Java [DE97, Nv98, Sym97]. 
Those proofs have not had to deal with JVML peculiarities (in particular, with 
subroutines); nevertheless, their techniques may be helpful in extending our work to 
the full JVML. 

In summary, there has not been much work closely related to ours. We do not 
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find this surprising, given that the handling of subroutines is one of the most original 
parts of the bytecode verifier; it was not derived from prior papers or systems [Yel97] . 
However, interest in the formal treatment of bytecode verification is mounting; sev- 
eral approaches are currently being pursued [FM98, Gol97, HT98, Qia98, Sar97]. 
Goldberg, Qian, and Saraswat all develop other formal frameworks for bytecode ver- 
ification, basing them on constraints and dataflow analysis; their work is rather broad 
and not focused on subroutines. Hagiya and Tozawa generalize our rules for subrou- 
tines. Building on our type system, Freund and Mitchell study object initialization 
and its problematic interaction with subroutines; work is under way on a subset of 
JVML that includes objects, classes, constructors, interfaces, and exceptions. 

10 Conclusions 

The bytecode verifier is an important part of the Java VM; through static checks, it 
helps reconcile safety with efficiency. Common descriptions of the bytecode verifier 
are ambiguous and contradictory. This paper suggests the use of a type system as 
an alternative to those descriptions. It explores the viability of this suggestion by 
developing a sound type system for a subset of JVML. This subset, despite its small 
size, is interesting because it includes JVML subroutines, a source of substantial 
difficulty in the design of a type system. 

Our results so far support the hypothesis that a type system is a good way to 
describe the bytecode verifier. Significant problems remain in scaling up to the full 
JVML, such as handling objects and concurrency. However, we believe that these 
problems will be no harder than those posed by subroutines, and that a complete 
type system for JVML could be both tractable and useful. 

Appendix 

A Proof of soundness for the structured semantics 

First, we prove that a step of execution preserves WFCallStack. Next, we prove some 
lemmas about types. Finally, we prove the soundness theorem for the structured 
semantics (Theorem 2), first by showing that well- typing of the stack is preserved 
and then by showing that well- typing of local variables is preserved. 

A.l Preservation of WFCallStack 

The following lemma states certain insensitivities of WFCallStack to the exact value 
of pc: 
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Lemma 1 For all P, F, and S such that F, S h s P: 

\/pc, pd , p. 

A WFCallStack(P, F, pc, p) 
A Rp,pc' = Rp,pc 
A Dom{Fp C ') = Dom{F p C ) 
=> WFCallStack(P, F, pd, p) 

Proof Assume that P, F, S, pc, pc', and p satisfy the hypotheses of the lemma. 
We do a case split on p: 

1. Case: p = e. In this case, the assumption WFCallStack(P, F, pc, p) must 
be true by rule (wfO), so Dom(Fpc) = Var. Given this and the assumption 
that Dom(Fp C /) = Dom(Fp C ), it follows that Dom(Fp C /) = Var. Thus, by 
rule (wfO), we can conclude that WFCallStack{P, F ,pd , p). 

2. Case: p ^ e. In this case, we know that p = p • p' for some p and p'. Also, the 
assumption WFCallStack(P, F, pc, p) must be true by rule (wfl), so, for some 
L, we know that 

P[p-1] = jsrL 
L 6 Rp^pc 
Dom(Fp C ) C Dom(F p ) 
WFCallStack{P,F,p, p') 

Substituting Rp^pa for i?p 5 pc an d Dom(Fp C >) for Dom(Fp C ), we have all we 
need to establish WFCallStack(P, F , pc 1 , p) by rule (wfl). 

□ 

Now we show that the structured dynamic semantics preserves WFCallStack: 

Restatement of part of Theorem 2 For all P, F, and S such that F, S h s P: 

Vpc, f,s,p,pc',f',s',p'. 

A P h s {pc, f, s, p) - (pc', /', s', //> 
A WFCallStack{P, F, pc, p) 
=> WFCallStack{P, F, pc' , p') 

Proof Assume that P, F, S, pc, f, s, p, pd , f, s' , and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, f, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We do 
a case split on the instruction possible at P[pc], proceeding in three cases: 
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1. The first case is instructions that do not affect the subroutine call stack: inc, 
if, load, store, pop, and pushO. For these instructions, their structured 
dynamic semantics implies that p' = p and their structured static semantics 
implies that Rp t pc = Rp,pc' and Dom(Fp C ) = Dom(Fp C >). Given these equal- 
ities, we can conclude WFCallStack(P, F,pd , p') by Lemma 1. 

2. The second case is P[pc] = jsr K for some K. In this case, the structured 
dynamic semantics implies that p' = (pc + 1) ■ p, so we want to show that: 

WFCallStack{P, F, K, (pc + 1) • p) 

To prove this judgment using rule (wf 1), it suffices to show: 

(a) that P[(pc+ 1) — 1] = jsr K, which we are assuming; 

(b) that K 6 Rp,K, which is true because Rp : x = {K} by the structured 
static semantics of jsr (specifically, line 3 of the jsr rule in Figure 7); 

(c) that Dom^Fx) Q Dom(F (pc+i)) , which also follows from the structured 
static semantics of jsr K (specifically, lines 2 and 3 of the jsr rule in 
Figure 8); 

(d) that WFCallStack(P,F,pc+l,p). We are assuming that 

WFCallStack{P, F, pc, p) 

From the structured static semantics of jsr K we know that Rp t (pc+i) = 
Rp,pc (line 2, jsr rule, Figure 7) and Dom(F (pc+i)) = Dom(Fp C ) (line 2, 
jsr rule, Figure 8). Under these conditions, 

WFCallStack{P, F, pc + 1, p) 

follows from Lemma 1. 

3. The third case is P[pc] = ret x for some x. The assumption that a step of 
execution is possible starting from {pc, f, s, p) implies that p is not empty If 
p is not empty, then by the structured dynamic semantics of ret we know that 
p = pd ■ p'. Given the assumption that 

WFCallStack{P, F, pc, p) 

by substitution we can conclude that 

WFCallStack(P, F, pc, pc 1 ■ p') 

This can be true only by rule (wf 1), so 

WFCallStack(P,F,pc',p') 

must be true. 

□ 
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A. 2 Lemmas about types 

A few lemmas about types are needed. The first lemma helps us reason about the 
types of locations at program points that dynamically follow a ret instruction: 

Lemma 2 For all P, F, and S such that F, S h s P: 

Vpc, f,s,p,p',x. 

A WFCallStack(P, F, pc, p ■ p') 
A P[pc] = ret x 

=> 

A Vy G Dom{F pc ). F p [y] = F pc [y] 
A S p = Spc 

Proof Assume that P, F, S, pc, f, s, p, p', and x satisfy the hypotheses of the 
lemma. The assumption WFCallStack(P, F,pc,p ■ p') must hold by rule (wfl), so 
there exists an L such that L 6 Rp t pc and P[p — 1] = jsr L. Given such an L, the 
conjuncts of the conclusion are instantiations of the quantified term found in the 
structured static semantics of ret (Figure 8). □ 

The following lemma states an insensitivity of T to the exact value of pc: 
Lemma 3 

VF,P,V,T, pc, pc'. 

A Dom(Fpc') = Dom(Fp C ) 
Ay€ Dom(Fpc) =>- F pc ,[y] = F pc [y] 
A T(F,pc,p)[y]=T 
^F(F,pd,p)[y]=T 

Proof Assume that F, p, y, T, pc, and pc' satisfy the hypotheses of the lemma. 

If y G Dom(Fp C ), then the assumption that J-{F, pc, p) [y] =T must be true 
by rule (ttO), so we can conclude that T = Fp C [y]. Given y € Dom{Fp C ), by 
assumption Fp C >[y] = Fp C [y], thus Fp C /[y] = T. Therefore, by rule (ttO) 

F(F,pd,p)[y]=T 

If y ^ Dom(Fpc), then T(F, pc, p)[y] = T must be true by rule (ttl), so we can 
conclude, for some p and p', that p = p ■ p' and that 

HF,p,p')[y]=T (1) 

Given the assumptions that y ^ Dom(Fp C ) and Dom(Fp C ) = Dom(Fp C i), it follows 
that y 0 Dom(Fp C /). Given this and (1), 

HF,pc',p)[y]=T 

follows from rule (ttl). □ 
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The next two lemmas say that T does not change as a result of executing a j sr 
or ret instruction. The lemma for jsr is: 

Lemma 4 For all P, F, and S such that F, S h s P: 

Vpc, /, p, L, y, T. 

A P[pc] = jsr L 
A f(F,pc,p)[y] = T 
=>F(F,L,(pc+l)-p)[y] = T 

Proof Assume that P, F, S, pc, f, p, L, y, and T satisfy the hypotheses of the 
lemma. We do a case split on y: 

• Case: y € Dom(FL), that is, y is one of the variables accessible in the sub- 
routine being called. By the structured static semantics of jsr (line 3 of jsr 
rule in Figure 8), Dom(FL) C Dom(Fp C ), so y is an element of Dom(Fp C ) as 
well. Given that y 6 Dom(Fp C ), the assumption that 

r(F,pc,p)[y] = T 

could be true only by rule (ttO), so we know that T = Fp C [y]- From y 6 
Dom{Fi) and the structured static semantics of jsr (Figure 8, line 5) it follows 
that F L [y] = F pc [y], so T = F L [y\. From y € Dom(F L ) and T = F L [y], it 
follows from rule (ttO) that 

F(F,L,(pc+l)-p)[y]=T 

• Case: y 0 Dom{Fi). We know that 

Dom(Fpc) = Dom(Fp C+ i) 
y G Dom(Fp C ) => F pc [y] = F pc+1 [y] 
F(F,pc,p)[y] = T 

The first two lines follow from the structured static semantics of j sr (Figure 8, 
lines 2 and 4); the last we are assuming. From Lemma 3 it follows that 

r(F,pc+l,p)[y] = T 

Since y 0 Dom{Fi J ), it follows from rule (ttl) that 

F(F,L, (pc + l)-p)[y]=T 

□ 



32 



The next lemma says for ret what the previous lemma says for jsr. Here, 
however, we need to assume that we have a well-formed subroutine call stack. 

Lemma 5 For all P, F, and S such that F, S h s P: 

Vpc, f,p,p',x,y,T. 

A WFCallStack(P, F, pc, p ■ pi) 
A P[pc] = ret x 
A r(F,pc,p-f/)[y] = T 
^f(F,p,p f )[y] = T 

Proof Assume that P, F, S, pc, f, p, p', x, y, and T satisfy the hypotheses of the 
lemma. We do a case split on y: 

• Case: y 6 Dom(Fp C ). Given the WFCallStack assumption plus the as- 
sumptions that P[pc] = ret x and y € Dom(Fp C ), we can conclude that 
F p [y] = Fp C [y] by Lemma 2. Given that y 6 Dom(Fp C ), the assumption that 

F(F,pc,p-p')[y] = T 

must hold by rule (ttO), so T = F pc [y] and thus T = F p [y]. The WFCallStack 
assumption could be true only by rule (wf 1), so Dom(Fp C ) C Dom(F p ) and 
y € Dom(F p ). Given T = F p [y] and y € Dom{F p ): 

F(F,p,p')[y] = T 

follows from rule (ttO). 

• Case: y ^ Dom(Fp C ). Given y ^ Dom(Fp C ), the assumption that 

F(F,pc,p-p')[y} = T 
could be true only by rule (ttl), so we can conclude 

F(F,p,p')[y] = T 



□ 



The final lemma says that T is defined when WFCallStack holds: 
Lemma 6 For all P, F, and S such that F,S h P: 

Vy, p, pc. 

WFCallStack(P, F, pc, p) 
^3T. F(F,pc,p)[ y }=T 
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Proof This lemma holds because WFCallStack ensures that Dom(F p ) = Var for 
some p in p, so we are guaranteed that rule (ttO) will apply for at least this p. 

More formally, assume an arbitrary y in Var and P, F, S such that F, S h P. 
We proceed by induction on p: 

• In the base case, p = e. Assume pc such that WFCallStack(P, F, pc, p). Be- 
cause p = e, this WFCallStack assumption could be true only by rule (wfO), 
so Dom(Fp C ) = Var and thus y G Dom(Fp C ). Therefore, by rule (ttO), 
F{F,pc,p)[y} = Fp C [y}. 

• In the inductive step, p = p ■ p' for some p and p' . Assume pc such that 
WFCallStack(P,F,pc, p). 

If y G Dom(Fp C ), then we can conclude F(F, pc, p) [y] = Fp C [y\ by rule (ttO). 
If y g" Dom(Fp C ), then we need to use the induction hypothesis: 

Vg. WFCallStack{P, F, q, p') => 3T. F(F, q, p')[y] = T 

Because p is not empty, the assumption WFCallStack(P, F, pc, p) could be true 
only by rule (wf 1), so WFCallStack(P, F,p, p'). This matches the antecedent of 
the induction hypothesis, so we can conclude that J-(F,p, p')[y] = T for some 
T. Thus, by rule (ttl), we can conclude that F(F, pc, p) [y] = T. 

□ 

A. 3 Preservation of stack typing 

We now turn our attention back to the soundness theorem. This subsection shows 
that the typing of the operand stack is preserved; the next shows that the typing of 
variables is preserved. 

Restatement of part of Theorem 2 For all P, F, and S such that F, S h s P: 

Vpc, f,s,p,pd,f,s',p'. 

A P h (pc, f, s, p) - (pc', f, s', p') 
A WFCallStack(P,F,pc,p) 
A Vy. 3T.F(F,pc,p)[y]=T M[y]:T 
A s : S pc 
=> s' : Spc> 

Proof Assume that P, F, S, pc, f, s, p, pc', f, s', and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, f, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We do 
a case split on the instruction possible at P[pc] : 
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1. The first case is ret. We know from the structured dynamic semantics of ret 
that s' = s and p = pd ■ p' . Given the latter equality and the WFCallStack 
assumption, Sp C > = Spc follows from Lemma 2. Given Sp C > = Spc, s' = s, and 
the assumption that s : Sp C , it follows that s' : Spc'- 

2. The second case is inc, pop, pushO, if, jsr, and store. 

Consider inc, for example. We know from the structured dynamic semantics 
of inc that s = n ■ s" for some integer n and value string s", and that s' = 
(n + 1) ■ s" . We know from the structured static semantics of inc that 

Spc = Sp C t = Int • a 

for some type string a. Given s : Spc, s = n ■ s" , and Spc = Int • a, it follows 
that s" : a. Given s" : a, s' = (n + 1) ■ s", and Spc' = Int • a, it follows that 
s' : Spc'. 

As another example, consider store x. We know from the structured dynamic 
semantics of store that s = v ■ s' for some v, and we know from the structured 
static semantics that Sp C = T ■ Spc 1 for some T. Given these equations and 
the assumption that s : Spc, it follows that s' : Spc' . 

The proofs for the other instructions in this category are along similar lines. 

3. The last case is load x. In this case, we use the assumptions to infer that f[x] : 
T for some T such that J-{F, pc, p)[x] = T. The structured static semantics for 
load says that x 6 Dom(Fp C ), so T{F, pc, p) [x] = T must be true by rule (ttO), 
so that T = Fp C [x\. We know from the structured static semantics of load x 
that Spc' = Fpc[x] ■ Spc, so Sp C > = T ■ Spc- We know from the structured 
dynamic semantics of load x that s' = f[x] ■ s. Given f[x] : T, s : Spc, 
s' = f[x] ■ s, and Spc' = T ■ Sp C , it follows that s' : Spc'- 

□ 

A. 4 Preservation of local variable typing 

Restatement of part of Theorem 2 For all P, F, and S such that F, S h s P: 

Vpc, f,s,p,pc',f',s',p',y. 

A P h s {pc, f, s, p) - {pd, f, s', p') 
A WFCallStack{P, F, pc, p) 
A s : Spc 

A 3T.T(F,pc,p)[y] = T A f[y] : T 
=> 3T'. F{F, pd, p')[y] =T'A f'[y] : V 
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This statement is stronger than that in Section 5.3 in that the quantifier for y has 
been moved to the top level. 

Proof Assume that P, F, S, pc, f, s, p, pd , f, s', p', and y satisfy the hypotheses 
of the lemma. Let T be a type such that F(F, pc, p) [y] = T and f[y] : T; by assump- 
tion, such a T exists. The assumption that a step of execution is possible starting 
from (pc, f, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We 
do a case split on the instruction possible at P[pc]: 

1. The first case is instructions that do not modify y or p: inc, if, load, 
pop, pushO, and also store x for x ^ y. For these instructions, it follows 
from their structured static semantics that Dom(Fp C ') = Dom(Fp C ) and that 
Fpc'lu] = Fpc[y] when y 6 Dom(Fp C ). It follows from their structured dy- 
namic semantics that p' = p. Thus, by Lemma 3, T(F, pd , p')[y] = T. What 
remains to be shown is f'[y] : T. It follows from the structured dynamic se- 
mantics of these instructions that f[y] = f'[y\; from f[y] : T and f[y\ = f'[y] 
it follows that f[y] : T. 

2. The next case is store y. By the structured static semantics of store y, 
y 6 Dom(Fp C /). Thus, by rule (ttO), !F(F, pd, p')[y] = Fp C /[y]. What remains 
to be shown is f'[y] : Fp C /[y]. The structured static semantics for store y 
says that Sp C = Fp C /[y] ■ Sp C >; the structured dynamic semantics for store y 
says that s = f[y] ■ Sp C >. Given these equations and the assumption s : Spc, it 
follows that f'[y] : F pc ,[y]. 

3. The last case is jsr L and ret x. We can conclude that T(F, pd , p')[y] = T 
by Lemma 4 when P[i] is jsr L and by Lemma 5 when P[i] is ret x. What 
remains to be shown is f'[y] : T. From the structured dynamic semantics of 
these instructions we know that f = f. Given f[y] : T and f[y] = f'[y], it 
follows that f[y] : T. 

□ 

B Proof of soundness for the stackless semantics 

This section proceeds roughly top-down, first stating a proposition and two lemmas, 
next using these to prove the soundness theorem for the stackless semantics, then 
proving the two lemmas. 

If F and S are a typing for P in the stackless semantics, then they are a typing 
for P in the structured semantics: 

Proposition 1 For all P, F, S, ifF,S\- P, then F, S h, P. 
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The proofs below implicitly use this proposition when they apply lemmas and theo- 
rems that have F,S \- s P in their hypotheses. 

The first lemma establishes a simulation between the structured semantics and 
the stackless semantics: 

Lemma 7 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pc',f',s'. 

A P h (pc, /, s) - (pc/, /', s') 
A Consistent(P, F, S, pc, f, s, p) 
=> V- ^ ^ (PC, /, s, p) - (pc', /', s', pf) 

The second lemma states that Consistent is preserved by the structured dynamic 
semantics: 

Lemma 8 For all P, F, and S such that F,S\- P: 

Vpc, f,s,p,pcf,f',s',f/. 

A P h s {pc, f, s, p) - (pc', /', s', p') 
A Consistent(P, F, S, pc, f, s, p) 
Consistent^, F, S' , pc' , f, s', pf) 

Given these two lemmas and the soundness theorem for the structured semantics, 
the soundness theorem of the stackless semantics follows directly. 

Restatement of Theorem 3 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pc',f',s'. 

API- (pc, f, s) - (pd, f, s') 
A Consistent(P, F, S, pc, f, s, p) 
A Vy. 3T.^(F,pc,p)[y] =TA/[y] :T 
A s : Sp C 
3p'. 

A Consistent(P, F, S, pc', f, s' , p') 

A Vy. 3T'. T{F, pc', p')[y) = T> A /'[y] : T' 

A s' : ^pc/ 

Proof Assume that P, F, S, pc, f, s, p, pc' , /', and s' satisfy the hypotheses of 
the theorem. Use Lemma 7 to pick p' such that 

P h s (pc, f, s, p) -> (pc, /', s, p) 

The first conjunct of the conclusion follows from our selection for p' and Lemma 8. 
The last two conjuncts follow from our selection for p' and Theorem 2. □ 
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B.l Analogous steps 

Restatement of Lemma 7 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pd,f',s'. 

A P h (pc, /, s) - (pc', /', s') 
A Consistent(P, F, S, pc, f, s, p) 
=> V- ^ h, (PC, /, s, p) - (pc', /', s', p') 

Proof Assume that P, F, S, pc, f, s, p, pc', /', and s' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, f, s) implies that P[pc] is defined; it also implies that P[pc] 7^ halt. We do a 
case split on the instruction possible at P[pc]: 

• For all instructions except jsr and ret, pick p' = p. A comparison of the 
structured and stackless dynamics in Figure 10 and Figure 6 shows that the 
conclusion of our lemma follows directly from our assumptions. 

• For jsr L, pick p' = (pc + 1) • p. Again, a comparison of Figures 10 and 6 
shows that the conclusion of our lemma follows from our assumptions in this 
case as well. 

• The case for the ret x instruction is the only complicated one. 

First, we show (by contradiction) that our assumptions imply that p has at 
least one element. If p had no elements, then the WFCallStack2 part of the 
Consistent assumption would have to be true by rule (wf20). This would 
require that Cp^ c be empty, but the stackless static semantics for ret x (line 2, 
ret rule, Figure 13) together with the relationship between Ftp and Cp imply 
that Cp t pc must have at least one element. Thus, WFCallStack2 cannot hold 
by rule (wf20). Instead, it must hold by rule (wf2l), so p must have at least 
one element. 

Therefore, p = p ■ p" for some p and p" . We let p' = p" . To prove that this 
selection of p' satisfies the conclusion, we need to show that: 

P h (pc, f, s, p) -> (pc, f, s', p") 

In order to establish this judgment, we must show that pc 1 = p. By the 
stackless dynamic semantics of ret x, pd = f[x], so this reduces to showing 
that f[x] = p. 

Because p has at least one element, the WFCallStack assumption must be true 
by rule (wf 1). From this we can infer that, for some L, P[p — 1] = jsr L and 
L G Rp,pc- 
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- Given P[p — 1] = jsr L and p = p ■ p', we know by rule (ll) that 
Ap(p) = L ■ X' for some A'. (As mentioned in Section 6.3, Ap(p) is always 
denned for well- typed programs when WFCallStack holds.) 

— Given that L £ Rp,pc, we know by the stackless static semantics of ret x 
that Fp C [x] = (ret-from L) (line 4, ret rule, Figure 13). We also know 
from the stackless static semantics of ret x that x 6 Dom(Fp C ) (line 3). 

Because p is not empty, the GoodFrameRets component of the Consistent as- 
sumption must be true by rule (gfrl). Given this, x 6 Dom(Fp C ), and 

Fp C [x] = (ret-from L) 

it must be the case that 

GoodRet(L, f[x], Ap(p),p ■ p') 
We know that Ap{p) = L ■ A', so by substitution: 

GoodRet(L,f[x],L- X',p-p') 
This could be true only by rule (grl), so we can conclude that f[x] = p. 

a 

B.2 Preservation of Consistent 

Expanding the definition of Consistent, we want to prove the following lemma: 

Restatement of Lemma 8 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pd,f,s',p'. 

A P h (pc, f, s, p) - (pc', /', sf, p') 

A WFCallStack{P, F, pc, p) 

A WFCallStack2(P, pc, A P (p), p) 

A GoodStackRets(Sp C , s, Ap(p), p) 

A GoodFrameRets(F , pc, {}, f,Ap(p),p) 

=>- 

A WFCallStack(P,F,pc',p') 

A WFCallStack2(P,pc',Ap(p'),p') 

A GoodStackRets(S p C ' , s' , Ap(p'), p') 

A GoodFrameRets(F , pd , {},/', A P (p), p') 

We prove this by assuming the hypotheses and proving separately each conjunct 
of the conclusion. We prove the first conjunct (preservation of WFCallStack) in 
Section A.l. We prove the remaining conjuncts below after we state and prove some 
miscellaneous lemmas. 
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B.2.1 Miscellaneous lemmas 



The following lemma describes how a program step can change Ap(p): 
Lemma 9 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pd,f',s',f/. 

A P h s (pc, f, s, p) - (pc', /', s', p') 
A WFCallStack{P, F, pc, p) 

=> 

A VL. (P[pc] = jsr L Ap(p') = L • A P (p)) 
A Vx. [P[pc] = ret x 3L. L • A P (p') = A P (p)) 

Proof Assume that P, F, S, pc, f, s, p, pel , f, s', and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, /, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We do 
a case split on the instruction possible at P[pc] : 

• jsr L: From the structured dynamic semantics of jsr L, p' = {pc+ 1) • p. By 
assumption, P[pc] = jsr L. Thus, by rule (11), Ap(p') = L ■ Ap(p). 

• ret x: From the structured dynamic semantics of ret x, p = pc' • p' . Thus, the 
WFCallStack assumption must be true by rule (wf 1), so P[pd — 1] = jsr L for 
some L. Thus, by rule (11), A P {p) = L ■ A P (p'). 

□ 

Lemma 10 For all P, pc, X, and p: 

WFCallStack2(P, pc, A, p) p and A have the same length 

This can be proven by induction on the derivation of WFCallStack2(P, pc, A, p). 

Lemma 11 For all K, p, A, p: 

K ^ A A A and p have the same length 
GoodRet(K, p, A, p) 

This lemma can be proven by induction on A using rule (grO) in the base case and 
rule (gr2) in the inductive step. 

The following lemma states an insensitivity of GoodRet: 
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Lemma 12 

VP,F,pc,p,p',L,X',v,K. 

A WFCallStack2{P, pc,L-X',p- p') 
A GoodRct{K, v,L ■ X',p ■ p') 
GoodRet(K,v,X',p') 

Proof Assume P, F, pc, p, p', L, A', v, and K satisfy the hypotheses of our 
lemma. The WFCallStack2 assumption implies that p' and A' have the same length 
(by Lemma 10). We proceed with a case split on p': 

• When p' is empty, so is A', thus GoodRet(K, v , A' , p') follows from rule (grO). 

• When p' is not empty, we proceed with a case split on K. When K ^ L, the 
GoodRet assumption must be true by rule (gr2), so 

GoodRet(K,v,X',p') 

The next case is K = L. Because p' is not empty, the WFCallStack2 assump- 
tion must be true by rule (wf2l), so L 0 A' and thus K ^ A'. Given this and 
the fact that A' and p' have the same length, we can conclude by Lemma 11 
that 

GoodRet(K,v,X',p') 

□ 

The next lemma is used to prove the following lemma: 
Lemma 13 

Vp,P,F,pc,p,f, f',x,v. 

A WFCallStack{P, F, pc, p) 

A /iC Dom(Fpc) 

A x 6 /i 

A /' = f[x ^ v] 

A GoodFrameRets(F , pc, p, f, Ap(p), p) 
GoodFramcRctsiF , pc, p, f',Ap(p),p) 

Proof We proceed by induction on p: 

• In the base case, p = e. Pick arbitrary P, F, pc, p, f, f, x, and v. In this 
case, GoodFrameRets(F , pc 1 , p, f , Ap(p) , p) follows from rule (gfrO). 
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• In the inductive step, p = p- p' for some p and p' . Pick arbitrary P, F, pc, p, f, 
/', x, and v. Assume all hypotheses of Lemma 13 hold. The GoodFrameRets 
assumption could be true only by rule (gfrl), so 

L ( a ¥JF$%L « ) - < 2 > 

and also 

GoodFrameRets(F, p, Dom(F pc ) , /, A P (//) , pi) (3) 
First, we want to show that 

V^- ( : FJFSSL L) ) * ^L.m^) (4) 

Assume y and L such that y is in Dom{Fp C )\p and .Fpc[y] = (ret-from L). 
Because x G /x, it must be that y ^ x, so by our assumption relating / to /', 
/[y] = /'[y]- Given this equality, GoodRet(L, f'[y],Ap(p), p) follows from (2). 

Next, we want to show that 

GoodFrameRets{F,p, Dom(F pc ), f',A P (p'),p') (5) 

We prove this using the induction hypothesis, which we instantiate as follows: 

A WFCallStack(P,F,p,p') 
A Dom(Fpc) C Dom{F p ) 
Ax£ Dom(Fpc) 
A /' = /[x h-» u] 

A GoodFrameRets{F,p, Dom{Fp C ), f,A P {p'), p') 
=>- GoodFrameRets{F ,p, Dom(Fp C ) , f , A P (p') , p') 

The first two antecedents of this instantiation of the induction hypothesis fol- 
low from the fact that the WFCallStack assumption must be true by rule (wf 1). 
The next antecedent follows from the assumptions that x £ p and p C 
Dom(Fp C ). The fourth antecedent we are assuming, and the last is (3). Thus, 
we can use the induction hypothesis to conclude (5). 

Given (4) and (5), 

GoodFrameRets(F ', pc, p, f ,Ap(p), p) 
follows from rule (gfrl). 

□ 
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The final lemma in this set states an insensitivity of GoodFrameRets: 
Lemma 14 

VP,F,pc,f,p,pc>,f',x,v,T. 

A WFCaUStack(P,F,pc,p) 

Axe Dom(F pc ) 

A /' = f[x i ^ v] 

A F pc , = F pc [x ^ T] 

A VK.T= (ret-from K) => GoodRet(K,v, A P (p), p) 
A GoodFrameRets(F , pc, {}, /, A P (p), p) 
=>- GoodFrameRets(F , pc', {}, /', A P (p), p) 

Proof Pick arbitrary P, F, pc, /, p, pc', /', x, v, and T. We proceed by a case 
split on p: 

• The first case is p = e. In this case, GoodFrameRets(F,pd ,{}, f , A P (p), p) 
follows from rule (gfrO). 

• The second case is p = p ■ p' for some p and p'. Assume all hypotheses 
of Lemma 14 hold. The GoodFrameRets assumption could be true only by 
rule (gfrl), so 

( A F^lr— a ) ^ ^e ( (L,/ b ],A P (p),p) (6) 

and also 

GoodFrameRets(F,p, Dom(F pc ), /, A P (p'), p') (7) 
First, we want to show that 

By assumption, Dom(Fp C >) = Dom(Fp C ), so (8) is equivalent to 

Assume y and L such that y is in Dom(Fp C ) and Fpc'ty] = (ret-from L). 
For y ^ x, GoodRet(L, /'[y], A P (p), p) follows from (6) and our assumptions 
relating / to /' and F pc to Fp C i. For y = x, GoodRet(L, f'[y], A P (p), p) follows 
from the assumption 

V-K". T = (ret-from if) GoodRet(K,v, A P (p), p) 
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Next, we want to show that 

GoodFrameRets{F,p, Dom(F pe ), f, Ap(p'), p') (9) 
By assumption, Dom(Fp C ) = Dom(Fp C >), so (9) is equivalent to 

GoodFrameRets(F,p, Dom(F pc ), f ,A P (p'), p') 

We prove this using Lemma 13. Our assumptions imply the following conclu- 
sions: 

WFCallStack(P,F,p,p') 
Dom(Fp C ) C Dom(F p ) 
x <E Dom(Fpc) 
f = f[x v] 

GoodFrameRets(F , p, Dom(F pc ) , /, A P (p') , p') 

The first two conclusions follow from the fact that p is not empty and thus 
the WFCallStack assumption can only be true by rule (wf 1). The next two we 
are assuming directly. The last conclusion is (7). These conclusions are the 
antecedents of Lemma 13, so (9) follows. 

Given (8) and (9), 

GoodFrameRets(F , pd , {},/', A P (p), p) 
follows from rule (gfrl). 

□ 

B.2.2 Preservation of WFCallStack2 

Restatement of Part of Lemma 8 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pd,f',s',p'. 

A P h s (pc, f, s, p) - (pd, f, s', p') 
A WFCallStack{P, F, pc, p) 
A WFCallStack2{P, pc, A P (p) , p) 
=> WFCallStack2(P, pd, A P (p') , pf) 

This restatement omits unneeded conjuncts in the hypotheses. 

Proof Assume that P, F, S, pc, f, s, p, pd , f, s' , and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, f, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We do 
a case split on the instruction possible at P[pc] : 
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• For all instructions except jsr and ret, we have p' = p (by the structured dy- 
namic semantics), so Ap(p') = Ap(p) (by substitution). Also, by the stackless 
static semantics of these instructions, Cp t p C ' = Cp,pc- Given these equations, 

WFCallStack2{P, pd, Ap(p'), p') 

follows from the WFCallStack2 assumption, whether that assumption is true 
by rule (wf20) or rule (wf21). 

• In the case of jsr L, we have L = pd (by the structured dynamic semantics). 
We first prove that the WFCallStack2 assumption implies that 

Ap(p) is a subsequence of Cp : p C (10) 

If p 7^ e, then WFCallStack2 must hold by rule (wf2l), so (10) must be true 
in this case. If p = e, then Ap{p) = e (by rule (10)) and Cp,pc = e (because 
WFCallStack2 must hold by rule (wf 20)), so (10) must be true in this case as 
well. 

We use rule (wf21) to show that WFCallStack2(P, pd ,A P (p'), p') is true. Ac- 
cording to this rule, it suffices to establish the following three intermediate 
results: 

1. L 0 Ap(p). This follows from (10) and L 0 Cp : p C , which follows from the 
stackless static semantics of jsr L (line 2, jsr rule, Figure 11). 

2. Ap(p') is a subsequence of Cp t p C >. From Lemma 9 we know that Ap(p') = 
L ■ Ap{p). Together with (10), this implies that 

Ap(p') is a subsequence of L ■ Cp^pc (11) 

From the stackless static semantics of jsr L, we know that 

L • Cp t p C is a subsequence of Cp t p C ' (12) 

(lines 4 and 5, jsr rule, Figure 11). Given (11) and (12), we can conclude 
that 

Ap(p') is a subsequence of Cp^pa 

3. WFCallStack2(P, pc + 1, Ap(p), p). We prove this in two cases, the first 
when the WFCallStack2 assumption is true by rule (wf20), the second 
when the WFCallStack2 assumption is true by rule (wf2l). In both of 
these cases we have Cp t p C +i = Cp t p C , which follows from the stackless 
static semantics of jsr L (line 3, jsr rule, Figure 11). 
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If the WFCallStack2 assumption is true by rule (wf20), then p, Ap(p), 
and Cp^pc must be empty. Given Cp^ c +i = Cp^p C , Cp : pc+i must be 
empty too. Thus, 

WFCallStack2{P, pc + 1, A P (p) , p) 
follows from rule (wf20). 

If the WFCallStack2 assumption is true by rule (wf 21), then there exist 
p, p", K, and A" such that 

P = P ■ p" 
A P (p) = K-X" 

K £ X" 

K ■ X" is a subsequence of Cp^pc 
WFCallStack2(P, p, A", p") ' 

Because Cp t pc+i = Cp t pc, K-X" is a subsequence of Cp^pc+i as well. Since 
K £ A", K-X" is a subsequence of C P , pc+1 , and WFCallStack2{P, p, A", p"), 

WFCallStack2{P, pc + 1, K ■ X",p ■ p") 

follows from rule (wf 21). Since p = p ■ p" and Ap(p) = K ■ A", we obtain 

WFCallStack2(P, pc + 1, A P (p) , p) 

• In the case of ret x, we know from Lemma 9 and from the structured dynamic 
semantics that 

A P (p) = L ■ Ap(p') 
p = pd ■ p' 

for some L. Applying these equations to the WFCallStack2 assumption, we 
can conclude that 

WFCallStack2{P, pc, L ■ A P (p'),pd ■ pi) 
This judgment can be true only by rule (wf 21), so we can conclude 

WFCallStack2{P, pc 1 , A P (p'), p') 

□ 
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B.2.3 Preservation of GoodStackRets 

Restatement of Part of Lemma 8 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pc',f',s',p'. 

A P h (pc, f, s, p) - (pc', f, s', p>) 

A WFCallStack(P, F, pc, p) 

A WFCallStack2(P, pc, A P (p), p) 

A GoodFrameRets(F , pc, {}, f,Ap(p),p) 

A ^ (jirfM™«-. r » L) ) G^ ((i ,*1,A,(p),p) 

Again, this restatement omits unneeded conjuncts in the hypotheses. Also, for con- 
venience, this restatement expands the definition of GoodStackRets. 

Proof Assume that P, F, S, pc, f, s, p, pc 1 , f, s', and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
{pc, f, s, p) implies that P[pc] is defined; it also implies that P[pc] ^ halt. We do 
a case split on the instruction possible at P[pc] : 

• First we look at all instructions except jsr and ret. For these instructions, 
p = p' by the structured dynamic semantics of the individual instructions; also, 
by substitution, Ap(p) = Ap(p') as well. 

Assume j and L such that j G Dom(Sp C >) and Spc'lj] = (ret-from L); we 
need to show that 

GoodRct(L,s'lj],A P (p'),p') 

This follows from rule (grO) when p' = e. Assume that p' ^ e and proceed 
with a case split on j: 

- The first case is stack slots that are unchanged, that is, stack slots that 
are not written by the instruction but rather are carried over. The exact 
set is going to vary by instruction, but values of j in this set will satisfy 
the following: 

j G Dom(Spc) A Spclj] = Spclj] A s'\j] = s\j] 

For these stack elements, if Spc'lj] equals (ret-from L), then Spclj] a ^ so 
equals (ret-from L). This implies GoodRet(L, slj], Ap(p), p), which by 
substitution means GoodRet(L, s'[j], Ap(p'), p'). 
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- The second case is stack slots that are written by the instruction. It turns 
out that this case applies only to load for the following reasons: 

* The instructions pop, if, and store do not write the stack, so this 
second case does not apply to these instructions. 

* For inc and pushO, if j is the element written (that is, the top el- 
ement of s'), we know from the stackless static semantics that the 
type Spc> [j] is Int, which violates our assumption that Spc 1 [j] equals 
(ret-f rom L) , so this second case does not apply to these instruc- 
tions either. 

For load x, we know from the stackless static semantics of load x that 
x 6 Dom(Fpc) and Fp C [x] = Sp C >[j]- Given the assumption that p' / 
e, the GoodFrameRets assumption must be true by rule (gfrl). The 
antecedents of this rule and the assumptions that x 6 Dom(Fpc) and 
Spc'[j] = Fpc[x] = (ret-f rom L) imply that 

GoodRet(L, f[x],A P (p),p) 

By the structured dynamic semantics of load x, s'[j] = f[x] and p' = p, 
so by substitution 

GoodRet(L,s'[j},A P (p'),p') 

• For jsr and ret, assume j and L such that j £ Dom(Spc') and Sp C >[j] = 
(ret-f rom L) ; we need to show that 

GoodRet(L,s'[j},A P (p'),p') (13) 

But first we prove a helpful fact. For both j sr and ret, when j £ Dom(Spc) we 
can assume that Spc[j] = Sp C '[j]- For jsr, this follows from the stackless static 
semantics (line 6, jsr rule, Figure 13). For ret, this follows from Lemma 2; 
to apply Lemma 2, we need that p = pd ■ p', which follows from the structured 
dynamic semantics of ret. 

Given Sp C [j] = Sp C >[j] for j € Dom(Spc), Sp C >[j] = (ret-f rom L), and the 
GoodStackRets assumption, we can conclude: 

j G Dom(Spc) => GoodRet(L,s[j],A P (p),p) 

Given this and the fact that s[j] = s'[j] for j € Dom(Sp C ) (which follows from 
the structured dynamic semantics of jsr and ret), we can conclude: 

j G Dom(Spc) => GoodRet(L,s'[j},A P (p),p) (14) 
Now we return to proving (13) for the cases of interest: 
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- In the case of jsr K, we do a case split on j: 

1. Case: j 0 Dom(Sp C ), that is, j is the index of the top of the stack. 
In this case we know from the stackless static semantics of j sr K that 
K = L (line 6, jsr rule, Figure 13), we know from the structured 
dynamic semantics that s'[j] = pc + 1 and p' = (pc + 1) ■ p, and we 
know by Lemma 9 that Ap(p') = L ■ Ap(p). Given these equations, 
(13) follows by rule (grl). 

2. Case: j G Dom(Spc)- In this case, we know from the stackless static 
semantics of jsr K that K ^ L (line 7, jsr rule, Figure 13). We 
know from the structured dynamic semantics that p' = (pc + 1) • p, 
and we know from Lemma 9 that Ap(p') = K ■ Ap(p). Given these 
equations and (14), (13) follows from rule (gr2). 

— In the case of ret, we know from Lemma 9 and the structured dynamic 
semantics that: 

A P (p) = K ■ Ap(p') 
p = pd ■ pf 

for some K. Given these equations, we prove (13) by cases on L: 

1. Case: K ^ L. By the stackless static semantics, Dom(Spc') is equal 
to Dom(Spc), so j 6 Dom(Spc)- Given this, the conclusion of (14) 
must be true. Given Ap(p) = L • Ap(p') and K ^ L, the conclusion 
of (14) can be true only by rule (gr2), so we can conclude 

GoodRet(K,s'[j},A P (p'),p') 

2. Case: K = L. From the WFCallStack2 assumption and Lemma 10 
we know that Ap(p) and p have the same length; given this, Ap(p') 
and p' must also have the same length. The assumption that a 
step of execution is possible starting from (pc, f,s,p) implies that 
p is not empty, thus the WFCallStack2 assumption must be true by 
rule (wf2l), so L ^ Ap(p'). Thus, (13) follows from Lemma 11. 

□ 
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B.2.4 Preservation of GoodFrameRets 

Restatement of Part of Lemma 8 For all P, F, and S such that F,S h P: 

Vpc, f,s,p,pd,f',s',f/. 

A P h {pc, f, s, p) - (pc', /', s', p') 
A WFCallStack{P, F, pc, p) 
A WFCallStack2{P, pc, A P (p), p) 
A GoodStackRets(S pc ,s,Ap(p),p) 
A GoodFrameRets(F , pc, {}, f,A P (p),p) 
GoodFrameRets(F, pc', {}, f',A P (p'), p') 

This time, we need all conjuncts in the hypotheses. 

Proof Assume that P, P, 5, pc, /, s, p, pc', /', s' , and p' satisfy the hypotheses 
of the lemma. The assumption that a step of execution is possible starting from 
(pc, /, s, p) implies that P[pc] is defined; it also implies that P[pc] 7^ halt. 
When p' = e, we have Ap(p') = e by rule (10). Thus, we can conclude 

GoodFrameRets{F , pc' , {}, f',A P (p'),p') 

by rule (gfrO). 

When p' is not empty, we do a case split on the instruction possible at P[pc]: 

• The first case is inc, pop, pushO, if, and load x for any x. It follows from the 
stackless static semantics of these instructions that Dom{Fp C ) = Dom{Fp C i) 
and, for all y in Dom(Fp C ), Fp C [y] = Fp C i[y]. It follows from the structured 
dynamic semantics of these instructions that f = f and p = p'. 

Because p is not empty, we can assume that p' = p ■ p" for some p and p" . The 
GoodFrameRets assumption must be true by rule (gfrl), so we can conclude 
that 

- ( 1 ^r=f/et- fr „, a ) - ^(L./M.ApM.p) 

A GoodFrameRets{F,p, Dom(F pc ), f,A P {p"), p") 

Using the equalities f = f, p = p', Dom(Fp C ) = Dom{Fp C i) and, for y in 
Dom(Fpc), F pc [y] = F pc >[y], we can conclude: 

A ( A ZZ^Lo, L) ) - GoodRetiL, /'M, Ap(p'), /) 

A GoodFrameRets(F,p, Dom{Fp C >), f',A P (p"),p") 
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From this we can conclude 

GoodFrameRets(F, pc' , {}, f ,A P (p'), p') 

by rule (gfrl). 

• The next case is store x. Let v and T satisfy s = v ■ s' and Spc = T ■ Spc'- 
We know these exist by the structured dynamic semantics and stackless static 
semantics of store x, respectively. We want to apply Lemma 14 to conclude: 

GoodFrameRets(F , pc 1 , {},/', A P (p), p) 

To do so, we must discharge the antecedents of Lemma 14. The first an- 
tecedent, WFCallStack, we are assuming. The second and third antecedents 
follow from the stackless static semantics and the structured dynamic semantics 
of store x, respectively. The fourth antecedent follows from the stackless static 
semantics. The fifth and sixth antecedents follow from the GoodStackRets 
and GoodFrameRets assumptions, respectively. Thus, we can indeed apply 
Lemma 14 to conclude 

GoodFrameRets(F , pc 1 , {},/', A P (p), p) 

The structured dynamic semantics of store x implies that p = p' . Substitut- 
ing, we get 

GoodFrameRets{F, pc' , {}, f',A P (p'),p') 

• The next case is j sr K . From Lemma 9 and the structured dynamic semantics 
of j sr K we know that 

Ap(p') = K ■ A P (p) 
p' = (pc + 1) ■ p 

f' = f 
pd = K 

From the stackless static semantics we know that 

Dom(F K ) C Dom(Fp C ) 
Dom(Fp C+ i) = Dom(Fpc) 

We want to prove: 

GoodFrameRets(F, pc' , {}, f',A P (p'),p') 
Substituting, this is equivalent to 

GoodFrameRets(F, K, {},f,K ■ A P (p), (pc + 1) ■ p) 
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To establish this via rule (gfrl), it suffices to show that 

v« t ( A y e Dom ( F K) \ 

y A = (ret-from L) j (15) 

=> G 00 ^(L,/[y],K-A P (p),(p C +l) ■ p) 

and also that 

GoodFrameRets(F,pc+ 1, Dom(F K ), f,A P (p), p) (16) 

To prove (15), we assume y and L such that y is in Dom(FK) and = 
(ret-from L) and show that 

GoodRet(L, f[y],K ■ A P (p), (pc + 1) • p) (17) 

To show this, first we show that 

GoodRet(L,f[y],A P (p),p) (18) 

If p is empty, then (18) follows from rule (grO). If p is not empty, then the 
GoodFrameRets assumption must hold by rule (gfrl). Given the first line of 
rule (gfrl) and the fact that y 6 Z)om(Fx) and Fx[y] = (ret-from L), (18) 
follows. We know K ^ L from the stackless static semantics of jsr K (line 8, 
Figure 13). Given this and (18), we can conclude (17) by rule (gr2). 

Next, we need to prove (16). If p is empty, then (16) follows from rule (gfrO). 
Otherwise, we assume that p = p • p" for some p and p" . Given p = p • p" , to 
establish (16) via rule (gfrl), it suffices to show that 

V "' £ - (:3*SK K)) ) - GoodRet(L, f[y],Ap(p),p) 

(19) 

and also that 

GoodFrameRets(F,p,Dom(F pc+1 ),f,Ap(p"),p") (20) 

Because p ^ e, the GoodFrameRets assumption must be true by rule (gfrl), 
so we can conclude that 

^' L - ( A "f € J v ] - Slfr. « ) * GoodRet(L, f[y] , Ap(p), p) (21) 
and also that 

GoodFrameRets(F,p, Dom(F pc ), f,A P (p"),p") (22) 
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To prove (20), we simply observe that, because Dom(Fp C +i) = Dom(Fp C ), 
(22) is equivalent to (20). 

To prove (19), we assume y and L such that y is in Dom{F pc+i)\Dom{F k) 
and Fp C+ i[y] equals (ret-from L) and show that 



From the stackless static semantics of jsr K (line 4, jsr rule, Figure 13), 
because y is in Dom(Fp C +i)\Dom(FK), we can conclude that Fp C [y] equals 
Fpc+i[y] which in turn equals (ret-from L). Also, given Dom{Fp C +i) = 
Dom(Fpc), we can conclude that y € Dom(Fp C ). Given (21), y 6 Dom(Fp C ), 
and Fp C [y] = (ret-from L), we can conclude (23). 

• The last case is ret x. From Lemma 9 and the structured dynamic semantics 
of ret x we know that, for some K: 



We want to prove: 

GoodFrameRets(F, pc' , {}, /', Ap(p'), pi) 
If p' is empty, then this follows from rule (gfrO). 

Otherwise, we have that p' = p ■ p" for some p and p". We are assuming that 



GoodRet(L,f[y},A P (p),p) 



(23) 



A P (p) = K ■ Ap(p') 
p = pc' ■ p' 
f' = f 



GoodFrameRets(F ', pc, {}, /, Ap(p), p) 



Applying the equations above, this is equivalent to 



GoodFrameRets(F, pc, {}, /' 



■i,K-Ap{pi),pd-pi) 



This must be true by rule (gfrl), so we can conclude that 




(24) 



=> GoodRct(L, f[y],K ■ A P {p'),pc' ■ p') 



and also that 



GoodFrameRets(F , pc' 



■i,Dom{Fp C ),f,A P {pi),pi) 



(25) 



53 



Because p' = p ■ p", (25) must be true by rule (gfrl), so 

(26) 

and also 

GoodFrameRets(F,p, Dom(F pc ,), f , A P (p"), p") (27) 

Because p/e, the WFCallStack assumption must be true by rule (wf 1), so 
P[pc' — 1] = jsr M for M such that Rp : pc = {M}. Given this, by the stackless 
static semantics of ret x (lines 2 and 5, ret rule, Figure 13), we know that, 
for y in Dom(Fp C ), Fp C >[y] = Fp C [y]. Combining this with (24), we get 

\fv L ( A V G Dom{ - F P^ \ 
\ A F pc /[y] = (ret-from L) J 

GoodRet(L, f[y],K ■ A P (p 1 ), pd ■ pf) 
Using Lemma 12 and the WFCallStack2 assumption, we can conclude 

"«- L - ( A FpX7=^"t-from L) ) GooARet(L, f[y\,k P {p'), //) (28, 
Combining (26) and (28), we can conclude 

^ (il^fiL « ) - ^ ef (L,/[ !/ ],Ap(p'),/) (29) 

Given (29) and (27), we can use rule (gfrl) to conclude 

GoodFrameRets(F, pd , {}, f,A P (p'),p') 

□ 

C Proof of main soundness theorem 

To prove Theorem 4, our main soundness theorem, we use two lemmas. This section 
first states these lemmas, proves the main soundness theorem, then proves the two 
lemmas. 

The first lemma says that well-typed programs get "stuck" only at halt instruc- 
tions: 
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Lemma 15 For all P, F, and S such that F,S h P: 

Vpc, /, s, p. 

A Consistent(P, F, S, pc, f, s, p) 
A Vy.3T.T(F,pc,p)[y} = T A f[y] : T 
A s : Sp C 
A pc e Dom(P) 
A P[pc] ^ halt 
^3pcf,f,s f .P\-(pc, f, s)^(pd, f, s') 

The next lemma takes invariants stated about individual steps of execution and 
extends them over multi-step execution sequences: 

Lemma 16 For all P, F, and S such that F,S h P: 

Vpc,/ 0 ,/,s. 

P h (1, / 0 , e> ^* (pc, f, s) 
^3p. 

A Consistent(P, F, S, pc, f, s, p) 

A Vy. 3T.T(F,pc,p)[y]=TAf[y}:T 

A s : S pc 

A pc £ Dom(P) 

We use these lemmas to prove the main soundness theorem: 

Restatement of main soundness theorem For all P, F, and S such that 
F,S\- P: 

Vpc,f 0 ,f,s. 

P\-(l,f 0 ,e)^*(pc,f,s) \ 
A ?pJ,f',s'.P\-{pc, f, s)^(pc', f, s') ) 
=>- P[pc] = halt A s : S pc 

Proof Assume that P, F, S, pc, f, and s satisfy the hypotheses of this theorem. 
Under this assumption, the second conjunct of the conclusion (s : Sp C ) follows 
directly from Lemma 16. 

We prove the first conjunct of the conclusion by contradiction. Assume that 
P[pc] ^ halt. Our previous assumptions about P, F, S, pc, f, and s imply the 
hypotheses of Lemma 16, so we can conclude that there exists p such that P, F, 
S, pc, f, s, and p satisfy all hypotheses of Lemma 15. However, the conclusion of 
Lemma 15 contradicts our assumption that 

?pc',f',s'.P\-(pc, f, s)^{pc', /', s') 

Thus, we are forced to conclude that P[pc] = halt. □ 



55 



C.l Making progress 

Lemma 15 says that a well- typed program does not get stuck unless it hits a halt 
instruction: 

Restatement of Lemma 15 For all P, F, and S such that F,S h P: 

Vpc, /, s, p. 

A Consistent(P, F, S, pc, f, s, p) 
A Vy.3T.f(F,pc,p)[y} =TAf[y] : T 
A s : S pc 
A pee Dom(P) 
A P[pc] ^ halt 
^3pc',f',s'.Ph{pc, f, s)^(pd, /', s') 

Proof Assume that P, F, S, pc, f, s, and p satisfy the hypotheses of the lemma. 
We proceed with a case split on the instruction at -Pfpc], constructing pd, /', and s' 
satisfying the stackless dynamic semantics of the instruction at P[pc\. 

• For load x, pushO, and jsr L, progress can always be made. For load x and 
pushO, s' = s, f = /, and pc 1 = pc + 1. For jsr L, s' = (L + 1) ■ s, f = f, 
and pd = pc + 1 . 

• For inc, if L, pop, and store x, progress can be made when the stack has at 
least one value of the appropriate type in it. The assumption that s : Spc plus 
the static constraints on Sp C for each instruction ensure that the stack does 
indeed have an appropriately typed value on top. For all instructions, assume 
s = v ■ s" for some v and s" . For inc, if L, and pop, we take /' = /; for 
store x, we take /' = f[x i— > v]. For if L, pop, and store x, we take s' = s" . 
For inc, v must be some integer n, and we take s' = (n+ 1) ■ s". For inc, pop, 
and store x, pd = pc + 1. For if L, v must be some integer n, and we take 
pc' = pc + 1 if n is zero and we take pc' = L for other values of n. 

• For ret x, progress can be made in states where f[x] is an address. The 
assumption that 

3T. T(F,pc,p)[x]=TAf[x}:T 

and the stackless static semantics of ret x imply that f[x] does contain an 
address. Thus, progress is possible, and we take pd = f[x], f = f, and s' = s. 

□ 
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C.2 Chained soundness theorem 

Before proving Lemma 16, we state and prove one more invariant about individual 
steps of execution: 

Lemma 17 For all P, F, and S such that F,S h P: 

VpcJ,s,p,pc',f',s'. 

A P h (pc, /, a) - (pd, /', s') 
A Consistent(P, F, S, pc, f, s, p) 
=>- pc' G Dom(P) 

Proof Assume that P, F, S, pc, f, s, and p satisfy the hypotheses of the lemma. 
The assumption that a step of execution is possible starting from (pc, f, s) implies 
that P[pc] is defined; it also implies that P[pc] ^ halt. We do a case split on the 
instruction possible at P[pc]: 

• For pop, pushO, inc, load, and store, pc 1 = pc + 1, and pc + 1 is constrained 
by the stackless static semantics of these instructions to be in Dom(P). 

• For if L, pc' equals either pc + 1 or L, depending on which way the branch 
goes. Both pc + 1 and L are constrained by the stackless static semantics of 
if L to be in Dom(P). 

• For jsr L, pc' = L, and L is constrained by the stackless static semantics of 
jsr L to be in Dom(P). 

• For ret x, we first show that our assumptions imply that p has at least one 
element. If p had no elements, then the WFCallStack2 part of the Consistent 
assumption would have to be true by rule (wf 20) . This would require that Cp^pc 
be empty, but the stackless static semantics for ret x implies that Cp^pc must 
have at least one element. Thus, WFCallStack2 cannot hold by rule (wf 20). 
Instead, it must hold by rule (wf2l), so p must have at least one element. 

Let p = p ■ p' for some p and p' . Using Lemma 7, we have that pd = p. The 
WFCallStack part of the Consistent assumption must be true by rule (wf 1), so 
P[p — 1] = jsr L for some L. From the stackless static semantics of jsr L we 
have that + G Dom(P) for all i such that P[i] = jsr L. Thus, substituting 
p — 1 for i, we can conclude that p, and thus pd , is in Dom(P). 

□ 

Lemma 16 applies Lemma 17 and Theorem 3 to multi-step executions starting 
from the initial state: 
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Restatement of Lemma 16 For all P, F, and S such that F,5h P: 

Vpc,/ 0 ,/,s. 

P h (1, f 0 , e) ^* (pc, f, s) 
^3p. 

A Consistent(P, F, S, pc, f, s, p) 

A Vy. 3T.T{F,pc,p)[y)=T Af[y):T 

A s : S pc 

Ape £ Dom(P) 

Proof Assume P, F, and S such that F,S h P and proceed by induction on the 
number of execution steps in P h (1, /o, e) ^* (pc, /, s): 

• In the base case, {pc, /, s) equals (1, /o, e), that is, no steps of execution are 
taken. In Section 3, it is assumed that P[l] is defined for all programs, so we 
can conclude pc € Dom(P). We pick p = e and observe that: 

A Consistent(P, F, S, 1, /o, e, e) 
AVy. 3T. r(F,l,e)[y] = TAf 0 [y]:T 
A e : Si 

Given the values of Fi, Si, and Cp : i it is not hard to check this. 

• In the inductive step, let (pc n , f n , s n ) be a state such that 

P I" (1, /o, e) ^* (pc n , f n , s n ) -> (pc, /, s) 

By induction, we know that there exists a p n such that: 

A Consistent(P, F, S, pc n , f n , s n , p n ) 

A Vy. 3T. ^(F,pc n , />„)[?/] = T A f n [y] : T 

A s n : S p c n 

A pc n G Dom(P) 

Our assumptions and these conjuncts satisfy the hypotheses of Theorem 3 and 
Lemma 17, so we can conclude that 

A Consistent(P, F, S, pc, f, s, p) 
AVy. 3T. T{F,pc,p)[y)=T A f[y] : T 
A s : Spc 
A pc £ Dom(P) 

a 
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